Summary: | Limited area assistants don't properly handle viewport rotation and image rotation | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | tomtomtomreportingin |
Component: | Tool/Assistants | Assignee: | Tiar <tamtamy.tymona> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahab.greybeard, halla |
Priority: | NOR | ||
Version: | 5.0.0-beta1 | ||
Target Milestone: | --- | ||
Platform: | Appimage | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/b2d8a1e2fa830da088fa19c936d4facdbe376a1a | Version Fixed In: | |
Sentry Crash Report: |
Description
tomtomtomreportingin
2021-08-20 07:13:09 UTC
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. |