GNOME Bugzilla – Bug 323114
a lot of noise in regions that are supposed to be transparent
Last modified: 2006-02-05 20:15:34 UTC
this happends in most the icons that are drawn by nautilus. I have librsvg compiled from todays CVS with no special compile flags.
Created attachment 55575 [details] screenshot showing the problem
The SVG file itself would be more interesting and helpful. Thanks.
OK, fixed.
Ah, I have this same problem, it seems to occur at small sizes only. I rendered the attached doodle (done in inkscape) at many different zoom levels. It begins at zoom level 0.12 (which is 82x116 pixels for the file in question). Sometimes it can be rendered properly at that size or smaller, but that is random (so i guess a memory initialization bug)
Created attachment 56323 [details] an SVG that renders with noise when shrunk small enough I used the following commandline: cat _tree.svgz | rsvg-convert -z 0.11 > _tree.png the noise doesn't always show up (only 2 in 3 times), rerun it if noise wasn't rendered.
I get this when rendering at -z 0.10
This has been fixed three times and the have been two regressions. Currently however it stands fixed.
It is improved in CVS. NOT fixed, just decreases the minimum size that this happens at. Try rendering my svg with -z <= 0.071 >= 0.08 now works fine for me ON THIS FILE. the following file gets noisy quite quickly -- at -z <= 0.90 I think it's a bug in rsvg-convert though, not librsvg. Because the same icon is used by Liferea and is scaled down to ~0.25 of it's original size (same for the others in the set). Though, I don't know whether GTK renders at normal size and then scales down, or renders at final size immediately. the first would avoid the problem, the second wouldn't (usually). The problem (with rsvg-convert, librsvg, or whichever it is specifically) seems to occur when one of the dimensions of the rasterized image drops below an absolute threshold.. I guess 56.
Created attachment 58680 [details] this svg evidences the problem at a relatively high zoom level.
fwiw, rsvg-convert isn't large enough or interesting enough to have bugs of its own.
wow, you seem to be right, but only using the conversion utility, not using rsvg-view. Reopening
This is a bug in Cairo/pixman. While librsvg creates an image surface from its own zeroed-out data when it calls cairo_image_surface_create_for_data() (the rsvg-view case), cairo does not do the same when in cairo_image_surface_create() (the rsvg-convert case). It may be that cairo expects us to call CAIRO_OPERATOR_CLEAR on the surface, but I contend that necessity is bogus, since the presumption should be "you get a blank surface by default", not "you get an undefined, probably corrupt surface by default". The following patch to cairo/pixman/src/icpixels.c fixes the problem. I'm going to re-file this against cairo. Index: pixman/src/icpixels.c =================================================================== RCS file: /cvs/cairo/cairo/pixman/src/icpixels.c,v retrieving revision 1.9 diff -u -p -u -r1.9 icpixels.c --- pixman/src/icpixels.c 25 Jun 2005 03:13:19 -0000 1.9 +++ pixman/src/icpixels.c 5 Feb 2006 17:49:34 -0000 @@ -72,6 +72,7 @@ FbPixelsCreate (int width, int height, i return NULL; buf = (pixman_bits_t *) ((char *)pixels + base + adjust); + memset(buf, 0, height * stride); FbPixelsInit (pixels, buf, width, height, depth, bpp, stride);
Please see cairo bug https://bugs.freedesktop.org/show_bug.cgi?id=5816. I'm closing this as NOTGNOME and pushing the responsibility onto cairo before its 1.2 release.
Created attachment 58774 [details] [review] workaround Heh - I just found similar results and was about to go and file a bug against cairo. Anyway, incase anyone is interested, here is a suitable workaround for rsvg-convert.
I'm not currently willing to apply this patch to librsvg unless Carl Worth convinces me that I'm wrong. But thanks for the patch. When you ask for a new surface, you should get a clear one by default. When you ask a friend for a piece of paper, you shouldn't get handed one that's been scribbled on plus a bottle of white-out :)
Created attachment 58776 [details] [review] preferable patch The above workaround isn't ideal, as you could still have the case when someone called rsvg_handle_render_cairo() on an image surface and they will see corrupted results. This patch fixes the issue without requiring a newer version of cairo, can be backed out pretty easily if cairo decides they were in error, and also removes an unecessary g_new0 now that we call CAIRO_OPERATOR_CLEAR.