Summary: | With HiDPI scaling, rotating canvas back and forth cause offset of viewport. | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | asrcpq |
Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | minor | CC: | alvin |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
asrcpq
2021-11-16 04:56:19 UTC
Can reproduce on a1f3b48. No, I don't think it is strictly limited to high-DPI scaling as I can also get the canvas to shift when using 100% scaling. Seems to me that it shifts more the slower you move the cursor while in the rotate action (which produces smaller angle deltas for each move events). `snapToDevicePixel` in `KisCoordinatesConverter::correctOffsetToTransformation` is there to ensure that the top-left corner of the image area always aligns with the corner of a screen pixel. From my understanding, this is necessary for the QPainter (non-OpenGL) canvas to draw the pre-scaled projection correctly. For both QPainter and OpenGL canvas, this also makes sure that when the canvas is at a right angle and with a canvas scaling of power-of-two (e.g. 50%, 100%, 200%) the image pixels align with screen pixels to produce a crisp display. The problem is that rotation is handled by delta which causes the rounding difference to accumulate. This is not even specific to rotation as just panning the canvas with the touch gesture can also produce an offset. To really eliminate such offsets, I think the canvas movements need to be handled by storing the transformation at the start of a gesture, then have the overall change caused by a gesture applied on top of that. Might need to ask Dmitry about that. *** This bug has been marked as a duplicate of bug 409894 *** |