When using the rotate canvas feature mapped to Spacebar + MMB, I am experiencing heavy canvas drift. This is, I presume, because it uses the mouse cursor as origin for the rotation.
You can push the canvas away by holding MMB during rotation and moving the cursor up. Instead of rotating, it seems to move the transform origin along the radial axis that does not affect the rotation itself.
The effect for individual rotations may be subtle, but they add up quickly. Resetting rotation does not recentre the canvas either.
I thought it was already reported but can’t find it again…
(searched with canvas rotation in the summary of a new report on Log in to KDE Bugtracking System)
Hey, I was looking for information on this. My Krita is suffering heavily from this bug. At first I thought this was a general Windows bug, but no, it didn’t happen on my other system when I tried it (or at least it was much less severe). I’m not quite sure what is the cause. I didn’t see the problem on Ubuntu, but that’s probably to be expected
Is anyone else experiencing it on their system?
I’m wondering if this is related to screen resolution. My system has 4K with 150% UI scale. The other system is 1440p 100% scale.
At any rate, I realized that a good workaround is to use discrete rotation (by fixed increments). That doesn’t drift at all.
From my understanding this is due to the math involved in the rotation calculation. At some point in time during the redraw function the canvas’ position is recalculated, and then the point is rounded down to the nearest whole coordinate. This is a small change, but because it does it once per frame these rounding downs add up to canvas movement that is worse on stronger systems. The canvas then drifts up and to the left because 0,0 is the top left of the screen.
Huh, that line tool behavior is weird! I think I encountered this as well, but I thought it was a quirk with pen pressure (or my failure to control the pressure correctly). I never saw this with mouse input.
But getting back to the issue at hand. Looks like you were right. Indeed, the rotation is calculated over and over with very small increments and applied each time. This means the error accumulates very rapidly, at least on some systems, apparently.
So anyway, I took a stab at it and I might have actually fixed it. You can see the results from my test below:
Live - Krita 5.1.5
Dev build with the fix - based on 4930b33b5ffe87820efee866274a13e67960722d
The change didn’t turn out too terrible (I think?), although hard for me to tell if it will play nicely with all potential dependencies (I have zero Krita development experience ). Essentially, I did the natural thing; Rather than applying many small angle increments, the rotation is always calculated from the stable initial state (when the user started dragging) and applied permanently at the end (when the user releases the keys). This way we avoid the issue of accumulating error.
I’ll eyeball the code again tomorrow and see about posting a patch.
That’s amazing! I really do hope it gets patched. It was mildly annoying but not enough to really cause a fuss. The line tool is definitely a bit more annoying.
I’ve been cursed with just enough coding knowledge to dredge through the Krita source and find the problem code, but not enough coding knowledge to actually fix it.
Let me know if you want to tackle the line tool pressure point rounding error too, I might be able to throw some commission your way for it if it’s within my budget as an artist lol
To be more specific with what’s happening, the line tool stores pressure readings in ‘points’ along the line, as you draw it. These points are positioned on the line, and every frame a function is called that rotates the points around the origin into their ‘new’ preview position. This rotation has a floor() in it, and because it’s drawn every frame, 200+ fps, the floor() adds up and the points slowly move up and to the left of the origin. This isn’t noticeable with the mouse because the first pressure point isn’t close to 0.
I never understood why they are adjusted from point to point on an angled line and not just stored in a one dimensional array from the start and applied to the angled line as needed, but that’s what I figured would be the best solution.
Still, I made some strides and engaged with the core developers. Debugged Android… Yeah, I’m hopeful the patch will make the cut. Will update here if anything interesting happens.
That would be great, I have now learned not to use this feature and instead rely on the rotate canvas shortcuts. Would love to use the fluid rotation method instead. Hope this makes it in!
Hi Guys, if you took the trouble to fix the rotation, look at the Pop-up Palette slider. Оn 5.1.5 (portable) I have it does not see the current rotation (applied by any alternative method), only what is done through the Pop-up Palette. I know that this problem is found in some 5.2 builds, and in older versions like 4.4.8 this problem was not.
If you have time and interest) Or supplement your existing reports about the rotation problem)
I checked the build 5.2 made a few days ago, the slider works fine, apparently I was worried about nothing)
You can see the results from my test below:
). Essentially, I did the natural thing; Rather than applying many small angle increments, the rotation is always calculated from the stable initial state (when the user started dragging) and applied permanently at the end (when the user releases the keys). This way we avoid the issue of accumulating error.
)