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 330055 - Wrong position of image
Wrong position of image
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
2.13.x
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-05 21:05 UTC by Emmanuel Pacaud
Modified: 2017-12-13 17:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test file (718 bytes, image/svg+xml)
2006-02-05 21:06 UTC, Emmanuel Pacaud
Details
Side by side comparison (14.94 KB, image/png)
2006-02-05 21:08 UTC, Emmanuel Pacaud
Details

Description Emmanuel Pacaud 2006-02-05 21:05:17 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.
Comment 1 Emmanuel Pacaud 2006-02-05 21:06:39 UTC
Created attachment 58781 [details]
Test file
Comment 2 Emmanuel Pacaud 2006-02-05 21:08:10 UTC
Created attachment 58782 [details]
Side by side comparison

(See you later for bug #330088 :) )
Comment 3 Caleb Moore 2006-02-06 01:04:21 UTC
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.
Comment 4 Emmanuel Pacaud 2006-02-06 06:02:22 UTC
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 ?
Comment 5 Caleb Moore 2006-02-06 15:24:49 UTC
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.
Comment 6 Dominic Lachowicz 2006-02-06 16:34:29 UTC
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.
Comment 7 Carl Worth 2006-05-04 20:21:25 UTC
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
Comment 8 Dominic Lachowicz 2007-07-24 21:34:42 UTC
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
Comment 9 GNOME Infrastructure Team 2017-12-13 17:27:12 UTC
-- 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.