GNOME Bugzilla – Bug 330055
Wrong position of image
Last modified: 2017-12-13 17:27:12 UTC
A new nitpicking bug. I've attached a file that renders incorrectly with librsvg. It's an embedded image scaled by a factor of 2, and moved 2 units right and 2 units down. When rendered at resolution 1 unit = 1 pixel, image edges should be perfectly sharp. I've also attached a side by side comparison of librsvg and inkscape outputs.
Created attachment 58781 [details] Test file
Created attachment 58782 [details] Side by side comparison (See you later for bug #330088 :) )
I had a big argument with Cairo developer Carl worth about this. It is a bigger problem when someone uses a single wide embedded image for a gradient. Regardless, cworth things that the best thing that cairo can do is to fade out slowly over the space of a pixel when two surfaces are mismatched in size. I'll leave this bug open to pester cworth but I don't think there is much that we can do here without cairo's cooperation.
I don't understand why cairo is involved in this bug. It looks like image is shifted by half a pixel in the two directions, and clipped to its correct bounding box (2, 2, 10, 10). What are the cairo calls used by librsvg to render this file ?
Yes, your right, looking at your rendered pixmap it appears that this report is about the older libart version where the bug is different. Never the less: in the newer, Cairo based version there is still a problem and this problem is most definently cairo's fault. It causes a fuzzyness around the borders that I don't personally like, but probably is not out of spec.
FWIW, if I render to a PNG using rsvg-convert, then render the PNG in EOG with image interpolation turned off, I get Emmanuel's left screenshot.
It should be quite possible to get the desired result here with cairo. There may be several things going on (here and in the other cases that Caleb and I discussed): 1) There's an outstanding bug in cairo about images being sampled in the wrong location (off by one-half pixel). There's a patch for that that will be applied to cairo soon, and that will help some of the problems. 2) Previously, cairo always defined samples lying "outside" the surface of a source surface pattern as transparent. This would lead to blurring that was undesired in some cases. The upcoming cairo 1.2 release will provide a new CAIRO_EXTEND_PAD which will define these samples as being the same color as the nearest pixel that is within the surface. (This extend mode already exists in cairo 1.1 development, but it appears it's not currently being exercised by the test suite.) So, I think the nastiest things that Caleb and I were looking at was a 1xN image scaled up to SxS*N. What we were seeing was a smear from the desired color to transparent. With (1) above fixed then what should instead be expected is a the desired color centered and fading to transparent on either side. Then if the fade-to-transparent stuff isn't desired, then the application code should set CAIRO_EXTEND_PAD instead of the default CAIRO_EXTEND_NONE. I'm not sure if either of those issues are to blame for the behavior seen in this bug report. But it's certainly suspicious until those are addressed. -Carl
I've got code that implements Carl's suggestions. However, I think that I'm bumping into this: CAIRO_EXTEND_PAD pixels outside of the pattern copy the closest pixel from the source (Since 1.2; not implemented for surface patterns currently) Since I'm creating the pattern from an image surface
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/5.