Temporarily torn rendering

[Thomas Mitterfellner]

There seems to be a regression in rendering (canvas update) behavior in trunk vs. 0.48.4.

When I have a star with 4 spikes, 430 px (diameter), at zoom level ~140%, it fills my whole canvas height. The rendering when rotating it is much cleaner in 0.48.4 than in trunk (rotation speed ~45°/s). I get much more artifacts of a partially redrawn shape in the trunk version (checked out on 25.12.2013).
Also there is a very noticeble lag in the redrawing of the bounding box in trunk, not present in 0.48.4.

I'm using linux (opensuse 13.1), cairo 1.12.16.
On IRC, su_v confirmed that "trunk doesn't update the screen as smoothly when rotating that star as stable" (OS X).

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 12974.

[Thomas Mitterfellner (tomm-sbox)]

Are there any news on this issue? It would be great if it could be addressed before the 0.91 release.

[jazzynico (jazzynico)]

Also reproduced on Xubuntu 16.04, Inskcape 0.92.x rev. 15055.

[Nick (inconvenienced-inker)]

Is there a reason that this issue is low priority? It seems like it's been much more prevalent since 0.91 (Possibly a side effect related to the Cairo change?), and it a pretty big workflow impediment. Randomly (but quite often) the canvas will not refresh itself after zooming, or undo action - You have to manually zoom in and out again to force a refresh, or if you hover your cursor over an area on the screen, it creates a torn version of what the canvas should be showing.

I'm using 0.92.2 on Windows.

[Patrick Storz (ede123)]

No, unfortunately raising priority won't change much as it won't change the fact that we're currently lacking experienced programmers familiar enough with the rendering pipeline...