SUMMARY Limited area assistants become a bit buggy when rotation gets involved. STEPS TO REPRODUCE (viewport rotation) 1. Select Assistant Tool with Vanishing Point (for example) and Limited Area checked. 2. Create an assistant. 3. Rotate the viewport 45 degrees (for example with the status bar). OBSERVED RESULT Assistant visually bleeds out. Snapping area isn't affected. EXPECTED RESULT The assistant doesn't bleed out. STEPS TO REPRODUCE (image rotation) 1. Select Assistant Tool with Vanishing Point (for example) and Limited Area checked. 2. Create an assistant, with a squarish area for better demonstration of the problem. 3. Rotate the image 45 degrees (for example with Image -> Rotate -> Rotate Image...). OBSERVED RESULT The limited area appears to be significantly squeezed. Snapping area seems to also be affected. EXPECTED RESULT The limited area should stay squarish. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.12.11 (Appimage) ADDITIONAL INFORMATION Angles of 90, 180, 270, 360 don't seem to be affected. Also, super cool feature!
I can confirm this for the 5.0.0-beta1 appimage on Debian 10. The limited area rectangle is rotated and snapping to assistant lines is confined within the rotated limited area rectangle. However, the assistant lines fill an invisible non-rotated content bounding box which tracks the horizontal and vertical extent of the rotated limited area box. I don't see the limited area as being squeezed, the assistant lines extend to fill a new (invisible) bounding box as noted above. This is more apparent if the limited area is made as a 'thin' rectangle instead of a square.
Tiar, can you take a look?
Git commit 843f2e8f15d9a9249393306fa1a1da382c142e4d by Agata Cacko. Committed on 07/09/2021 at 20:07. Pushed by tymond into branch 'master'. Fix previews of various local assistants Before this commit, some assistants wouldn't handle a rotated canvas correctly (the preview would bleed out of the local area), and the previews behaviour was inconsistent between different assistants. This commit fixes the previews and makes it consistent: - both the static (depending only on the assistant) and dynamic (depending on the mouse position) previews are always visible - both previews are always limited to the local area (except for the parallel ruler which doesn't have any static preview except for the exact line that was drawn, which is fully visible no matter the local area - it could be fixed at a later date if it turns out to be a big issue). M +17 -18 plugins/assistants/Assistants/ParallelRulerAssistant.cc M +11 -8 plugins/assistants/Assistants/TwoPointAssistant.cc M +15 -16 plugins/assistants/Assistants/VanishingPointAssistant.cc https://invent.kde.org/graphics/krita/commit/843f2e8f15d9a9249393306fa1a1da382c142e4d
Git commit b2d8a1e2fa830da088fa19c936d4facdbe376a1a by Halla Rempt, on behalf of Agata Cacko. Committed on 08/09/2021 at 07:31. Pushed by rempt into branch 'krita/5.0'. Fix previews of various local assistants Before this commit, some assistants wouldn't handle a rotated canvas correctly (the preview would bleed out of the local area), and the previews behaviour was inconsistent between different assistants. This commit fixes the previews and makes it consistent: - both the static (depending only on the assistant) and dynamic (depending on the mouse position) previews are always visible - both previews are always limited to the local area (except for the parallel ruler which doesn't have any static preview except for the exact line that was drawn, which is fully visible no matter the local area - it could be fixed at a later date if it turns out to be a big issue). (cherry picked from commit 843f2e8f15d9a9249393306fa1a1da382c142e4d) M +17 -18 plugins/assistants/Assistants/ParallelRulerAssistant.cc M +11 -8 plugins/assistants/Assistants/TwoPointAssistant.cc M +15 -16 plugins/assistants/Assistants/VanishingPointAssistant.cc https://invent.kde.org/graphics/krita/commit/b2d8a1e2fa830da088fa19c936d4facdbe376a1a
Limited area assistants still don't handle image rotation properly from what I can tell. As in, rotating the image with Image -> Rotate -> Rotate Image. Is that intentional?
Testing with the Sept 15 5.1.0-prealpha (git 9005f1b) appimage and the Vanishing Point assistant: Rotating the canvas with the status bar widget seems to work perfectly. Rotating by Image -> Rotate -> Rotate by 90 degrees a number of times is ok. Rotating by a variable amount of about 30 - 45 degrees causes the limited area rectangle to change from squarish to a 'stretched' rectangle. On two occasions, the entire image doubled in size from 2048 x 2048 to 4096 x 4096 and then went up to 5695 x 5694 At all times, the assistant lines and the preview line were within the limited area, even if that area changed as noted above.
I, uhh, don't think it's fixable for now at all, then. I thought you were just talking about the preview, which I fixed. But if you use the Image -> Rotate, there is no way to keep the same local area, because it's defined by two points, which means it's always rectangular with edges parallel to the canvas edges. I'm not sure if I can even make it any better. You might need to define the area again if the new one doesn't fit you... I mean, at least for now, it's how they work and how they're defined.
Yea don't mind it that much, was just wondering.
Testing with the Sept 17 5.1.0-prealpha (git 09aee17) appimage: When the canvas is rotated using the control on the status bar, everything is fine. I think this is because that is a rotation of the composited image. Using Image -> Rotate -> Rotate Image causes problems: Multiple rotations of 90 degrees are ok. A rotation between 1 and 98 degrees causes a change to the aspect ratio of the limited area and also an increase in size of the canvas. The largest change to aspect ratio and canvas size increase happens with a 45 degree rotation.