Image pixels don't align with grid

Originator: NO

The used zoom level in that screenshot is 10631%. With a multiple of 100
(eg 10600) the error is less extreme.

I used the latest build to test this and I couldnt reproduce it (both the stable 0.45 and dev 0.46). I zoom all the way to 25600% and everything was perfectly aligned even with the snap off (using toolbar X and Y boxes).

Could you please download a newer release and check if the problem still exists.

Closing due to being out of date and lack of follow-up, but, please reopen with the requested info if you would like us to look into it further.

Still reproducible with Inkscape SVN.

This only happens with non-power of two zoom ratios. Try 8441% zoom.

Confirmed with current SVN. Daniel, thanks for following up.

This is because libnr, which handles the mapping from the image pixels to screen pixels, has a fixed point precision of 12 bits. increasing this precision to 17 or 18 bits (on line 42 in libr/nr-compose-transform.cpp) fixes this issue, but I have no idea about any possible side effects (e.g. regarding the chances of overflowing, 32 vs. 64 bits CPUs and OSes etc.).

Another solution is to make libnr floating point in some places. I've added a patch for this which demonstrates this, but this patch will currently only work when oversampling has been disabled in the preferences and when Inkscape has been compiled without the MMX extensions. Again, I don't have a clue about the side effects here. For example, what's the speed penalty? We need someone with a degree in computer science here. And that's not me ;-)

Some simple measurements showed that using "double" increased the rendering time with with 18%, whereas "long long" needed only 5% extra time (measured with oversampling turned off, making this a worst-case scenario for the relative measurement). So I've prepared a patch using "long long" and attached it to this bug report.

Now I'll leave it up to the release wardens to have a quick look and to decide whether this should be included in v0.47.

Thanks Diederik! This is an old and very annoying bug, and your patch fixes it. I committed it in 22228. The slowdown is unfortunate, but since it affects only images it shouldn't be so bad.

This patch seems to cause some troubles with 32 bit operating systems, so I will have to look into this again. For now it has been reverted though.

See

http://www.nabble.com/Imported-PNG-file-not-displayed.-td25473063.html

for more details

I've managed to reproduce the problems caused by my patch; the problems arise when the processor's MMX instructions are used. A small part of Inkscape has been written in assembly code to speed up the rendering and to be able to use the MMX instructions. This code needs to be changed too to handle the long long integers. Unfortunately, I cannot fix this because my only assembly experience was on a Motorola 68000 processor ;-). For now I've fixed my patch (see the attached ...v3) by limiting it to the non-MMX c++ code. Now let's try to find someone who can port this to the assembly code too. Until then this bug cannot be completely solved, unless we switch to using Cairo instead of libnr.

Committed in r22289. Thanks Diederik for all of your efforts!

Reverted patch in trunk until it can be tested further

This patch was reverted because it prevented the anti-aliasing of bitmaps, as reported in bug #437384. Man, we really do have a good quality department! :-)

Anyway, my patch fixed the original rounding error but introduced a new one which led to this. This has been fixed in the latest patch, which I've attached to this report (the ...v4). It will be applied (and thoroughly tested) immediately after our v0.47 release.

This patch does not yet fix the original bug when the CPUs mmx extensions are used. The mmx optimized code however should be removed because my measurements show that it does not improve the rendering performance, in fact it even makes Inkscape slower! Discussion on this is still pending though, see

http://www.nabble.com/Imported-PNG-file-not-displayed.-to25473063.html