After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 605875 - Gaussian blurred objects are sometimes missing
Gaussian blurred objects are sometimes missing
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
2.26.x
Other Linux
: Urgent major
: ---
Assigned To: Federico Mena Quintero
librsvg maintainers
: 680868 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-01-02 00:42 UTC by Gaz Davidson
Modified: 2015-03-29 21:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Object which disappears when blur > 0 (1.39 KB, image/svg+xml)
2010-01-02 00:42 UTC, Gaz Davidson
  Details
Hacky fix (369 bytes, patch)
2010-02-28 21:10 UTC, Gaz Davidson
needs-work Details | Review
Patch for librsvg bug #605875 (6.33 KB, patch)
2012-11-20 03:51 UTC, Eduard Braun
none Details | Review
Fix regression introduced with previous patch (7.15 KB, patch)
2012-11-20 23:07 UTC, Eduard Braun
none Details | Review

Description Gaz Davidson 2010-01-02 00:42:31 UTC
Created attachment 150659 [details]
Object which disappears when blur > 0

Some objects in my SVG files don't render over on Wikipedia, Mediawiki uses Imagemagick to convert SVG files to PNG for browser compatibility. Further investigation shows that this problem also shows up in Eye of GNOME, GIMP and the preview in Nautilus, all of which use librsvg. Mozilla, WebKit and Batik all work fine.

This only seems to happen to small Gaussian blurred objects. Wikipedians are also complaining that large Gaussian blurred objects are sometimes rendered in the wrong place, but I was unable to reproduce this one.

I have attached the simplest test case I was able to create, it is a small shape scaled up blurred the blur set to 0.1. Setting the blur value to 0.0 in Inkscape causes the object to reappear.

The object is taken from the top jewel of the crown in this image, which is also missing in librsvg:
http://commons.wikimedia.org/wiki/File:Kaliningrad_Oblast_Coat_of_Arms_2006.svg
Comment 1 Gaz Davidson 2010-02-28 21:10:49 UTC
Created attachment 154914 [details] [review]
Hacky fix

In rsvg-filter.c, the function fast_blur, uses "if (kx < 1 && ky < 1) return;" as an early-out to avoid blurring things by 0x0 pixels.

This causes an empty output buffer, so Gaussian blurred objects with a tiny bit of blur (resulting in 0 pixels) don't fill the output buffer at all and are therefore skipped.

This patch just sets such objects to a 1x1 blur, a better fix would be to detect this condition and avoid blurring at all creating an output buffer in the first place (this may cause jaggies and would require some code refactoring).

I tried several SVG files with this fix, including some from Wikipedia, the test case from this bug and the Audacity icon rendered at 40x40px. Although not ideal, does seem much better than the current behaviour.
Comment 2 Berkut Vladimir 2012-02-12 22:36:00 UTC
Blur bug still persists.

Example: http://imgh.us/Locked.svg

I created it with inkscape. Blur filter values from 0.1 till 1.9 cause objects to disappear, except when very HIGH zoom level is used - this is only in gnome3 nautilus and eye of gnome. Firefox is rendering fine.
Comment 3 houz 2012-03-31 19:53:09 UTC
This bug can still be confirmed with version 2.36 from debian sid. It's quite annoying to have single objects disappear when zomming out of a svg file in applications using rsvg (like darktable). Is there anything I could do to help getting this fixed?
Comment 4 Christian Persch 2012-04-05 19:44:38 UTC
Needs someone to produce a real fix (not a hack like attachment 154914 [details] [review]).
Comment 5 Eduard Braun 2012-11-18 02:30:41 UTC
Are there any news on this bug?

It should definetly be fixed since it also affects all Wikimedia projects (see bugreport there https://bugzilla.wikimedia.org/show_bug.cgi?id=42090).
Comment 6 André Klapper 2012-11-18 11:46:10 UTC
Eduard: Everyone wants to help, but no one else has any obligation to fix the bugs you want fixed. There are no news on this bug, otherwise they would be shown here.
Comment 7 Eduard Braun 2012-11-20 03:50:57 UTC
André: If everyone wanted to help, the bug probably would have been fixed already, sadly we were not that lucky. I surely know nobody has any obliagtion to fix the bug. Nevertheless I know the business and that a little reminder from time to time can cause a miracle now and then. Especially in this case there was some favorable progress on the bug but it seems it was getting out of sight afterwards.
Comment 8 Eduard Braun 2012-11-20 03:51:05 UTC
Created attachment 229440 [details] [review]
Patch for librsvg bug #605875

Since it seems unlikely to me this bug will get fixed in the near future but is maddening me whenever I stumble across a rendering bug on Wikipedia I went forward myself and created a patch.

The patch fixes both:
a) The problem with blurred nodes not shown at all
b) Some blurred nodes shown totally off the intended position

The patch still does not show blurring on very small nodes (they are displayed but without any blurring). This is due to the design of the filter feGaussianBlur within librsvg. Since we're using three box blurs to do a fast approximation of the Gaussian kernel, objects with a kernel width of 1 pixel or below can't be blurred anymore.
Comment 9 Eduard Braun 2012-11-20 23:07:44 UTC
Created attachment 229516 [details] [review]
Fix regression introduced with previous patch

A small fix I included in my previous patch actually introduced a regression that wasn't visible on the testcases I tried by then. I removed it until a better fix is found (probably it would also be OK to leave it the way it works now).


At the same time I found a potential issue that was already in the original code:

Cairo stores pixel values in an ARGB32 format (4 bytes of color values). These 32 bit of data are stored in machine specific endianness.

Right now we're therefore iterating through the color values in "arbitrary" order depending on the systems architecture (by separating the 32 bytes of the pixel in four uchars). So far this works because the code isn't dependent on what color channel it currently works on.

However the original code was designed to skip "unused channel" (I don't know if this is actually possible in SVG?) and would probably fail if used on the wrong architecture. Therefore I removed this code (in the worst case we'd do some unnecessary work here, in the best case it simplifies code a bit and won't show any effect ever).
Comment 10 Emmanuel Pacaud 2012-11-21 13:38:12 UTC
Review of attachment 229440 [details] [review]:

I have more or less imported this patch as is into lasem, for the blur offset fix part, as lasem uses almost the same code for gaussian blur. It works fine here.

I have also tested this patch in librsvg, where it fixes both the disappearing object issue and the blur offset issue. For me the code looks fine.
Comment 11 Emmanuel Pacaud 2012-11-21 13:39:06 UTC
Oh, I've tested attachment 229516 [details] [review], not 229440.
Comment 12 Eduard Braun 2013-11-15 01:42:44 UTC
Any chance of getting this patch into trunk?

This bug is *very* inconvenient on Wikipedia were rsvg is used as the sole SVG renderer and it would be great if it could be finally resolved for good.
Comment 13 André Klapper 2014-03-14 11:12:21 UTC
chpe: 
Can the patch get a review (and merge) please? Emmanuel tested it.
Comment 14 Aulbee 2014-09-25 12:44:26 UTC
The blur offset issue wreaks havoc on drop shadows and 3D lighting effects. Please, please incorporate the patch referred to above.
Comment 15 Matthias Clasen 2015-03-05 12:59:02 UTC
*** Bug 680868 has been marked as a duplicate of this bug. ***
Comment 16 Federico Mena Quintero 2015-03-13 18:18:10 UTC
Based on Eduard's patch, I'm putting in a patch to use a real gaussian blur instead of a box blur for small blurs - this should give us better quality.
Comment 17 Federico Mena Quintero 2015-03-13 18:20:15 UTC
Upping importance since this affects Wikimedia.
Comment 18 Federico Mena Quintero 2015-03-24 20:01:35 UTC
Fixed in commit 054807726db76558728e7a7513aabc4698b3dc95.
Comment 19 Derk-Jan Hartman 2015-03-29 21:10:13 UTC
Thank you Federico !!!