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 337995 - Anti-aliasing produces inaccurate rendering
Anti-aliasing produces inaccurate rendering
Status: RESOLVED NOTGNOME
Product: librsvg
Classification: Core
Component: general
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-10 18:14 UTC by Alexander “weej” Jones
Modified: 2006-07-07 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
two circles. no black halo should be visible on a white background (2.52 KB, image/svg+xml)
2006-04-10 18:15 UTC, Alexander “weej” Jones
Details

Description Alexander “weej” Jones 2006-04-10 18:14:42 UTC
See attached SVG file.

It contains two circles, one on top of the other. The bottom circle is black, the top one is white. Viewing the SVG on a white background clearly shows a black halo.

This really does actually screw up some of my drawings, for example when you have two rings, one inside the other, there is a tiny transparent part between the two rings which shouldn't be there.

Making a wild assumption, it appears to be that each SVG object is rendered anti-aliased, then composited together afterwards. This is what introduces the errors.

For a 100% accurate drawing, the entire canvas should be super-sampled, not just the individual objects. I don't know how much slower this is, but I'd really rather see it working properly than working quickly.

Cheers guys! Spread the GNOME ♥! </hippy-crap>
Comment 1 Alexander “weej” Jones 2006-04-10 18:15:19 UTC
Created attachment 63179 [details]
two circles. no black halo should be visible on a white background
Comment 2 Dominic Lachowicz 2006-04-10 18:34:05 UTC
Firefox's SVG renderer suffers from the same problem, for what it's worth.

You marked down 2.12.x as the version. Could you try out 2.14.x too? Thanks.
Comment 3 Caleb Moore 2006-04-13 17:59:58 UTC
We don't supersample anything btw, antialiasing is done through calculating pixel coverage I believe.

Honestly, I think this is not something that can be changed in librsvg but in cairo.
Comment 4 Alexander “weej” Jones 2006-04-14 11:38:45 UTC
Ah, interesting. In that case, I'd guess patching Cairo to supersample everything would be quite detrimental to desktop performance.

As far as I am aware, Macromedia Flash doesn't suffer from this problem. They give you three modes of quality, "low", "medium" and "high", which seem to reflect the supersampling multiplier. Perhaps this could be a Cairo setting? That way, people with slower computers could turn off all anti-aliasing if they wanted.

My own experience of dealing with anti-aliasing is limited to GD in PHP. I found that 16x supersampling gave excellent results, but was pretty slow. I'm guessing the same would be true of Cairo. :(
Comment 5 Alexander “weej” Jones 2006-04-14 13:56:12 UTC
Should we move this to Cairo?
Comment 6 Alexander “weej” Jones 2006-07-07 14:29:45 UTC
I have filed this upstream.

https://bugs.freedesktop.org/show_bug.cgi?id=7114