SUMMARY Undoing trimming the image to selection causes the selection to jump to a wrong location in the image while retaining its shape. STEPS TO REPRODUCE 1. Select part of the image with rectangle (or any) tool 2. Image -> Trim to selection 3. Undo OBSERVED RESULT Selection is not in the place where you originally selected, though it is the same shape EXPECTED RESULT Undo should restore the previous state of the program SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Every time you undo/redo, the selection shifts some more by some fixed amount, it seems.
I don't see any sign of this with Krita 4.2.6 on Windows 10 after repeated Trim to Selection followed by Undo actions. I used a simple newly created document with one transparent layer over the standard white background. Can you provide before and after screenshots to illustrate what you see?
Created attachment 122643 [details] initial selection
Created attachment 122644 [details] step 2: trim to selection For a split second when selecting trim to selection, the selection appears offset from the resized image boundaries, before jumping into place. That offset appears to be exactly the offset that gets applied to the selection when you undo the operation.
Created attachment 122645 [details] step3: undo
Created attachment 122646 [details] step 4: redo and undo again
looking at these images, I am almost certain that the offset applied is exactly the offset of the selection to the top left corner of the image. Some correction term getting applied twice somewhere.
also happens in the Linux 4.2.6 appimage. In fact, I scribbled on the transparent layer and in addition to the selection being shifted down and right, the top layer got shifted up and left so that the scribble was cut off. But while the selection bug happens every time, the layer getting shifted is hard to reproduce.
In all cases, however, there is a short interval after cropping/undoing when everything is shifted (the layers slide out of the image boundaries and the selection is out of bounds) before it corrects itself. I guess sometimes it doesn't correct itself.
With the 4.2.6 appimage on Linux, I don't have that offeset after Undo. I do see the transient selection offset as Trim is being performed (especially now I'm replicating your image and using a small selection). The transient offset appears to be equal to the initial selection offset from the top left corner, as you noted. Even with a large selection, I don't see any transient shift in the image layer itself. I've tried it with Image Preview on/off and Graphics Acceleration on/off and that made no difference. Does that make any difference for you? My PC is not particularly powerful (2x Xeon E5450 @3GHz): Hardware Information GPU Acceleration: auto Memory: 16039 Mb Number of Cores: 8 Swap Location: /tmp OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 750 Ti/PCIe/SSE2" Version: "4.6.0 NVIDIA 418.74" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false I can't think of anything else to try.
I'm starting with the 1024x1024 texture preset. Though that wasn't the only one that caused the bug, that's the one I'm on now, if it helps. I've done nothing aside from start the program and create a new canvas before crop and undo. Large selections are affected too, and shift out of bounds. Happens to me both in Linux and Windows, but on the Linux workstation, specs are: Ubuntu 18.04 Graphics: Quadro RTX 8000 Memory: 50GB Krita renderer: OpenGL Scaling mode: High quality filtering What you posted looks like a debug dump from krita but I'm unfamiliar with that feature, so hopefully that's good enough.
Hardware Information GPU Acceleration: auto Memory: 48201 Mb Number of Cores: 40 Swap Location: /tmp OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "Quadro RTX 8000/PCIe/SSE2" Version: "4.6.0 NVIDIA 435.12" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false == log == Supported renderers: QFlags(0x2|0x4) Surface format preference list: * QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) 2 * QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) 4 Probing format... QSurfaceFormat::DefaultColorSpace 2 Found format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) 2
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
also verified on my mac. Strange that there are reproducibility problems on your end.
I can confirm this bug. This happens only with selections made dragging the cursor Rectangle Circle Outline Tested in master and 4.2.6
The bug has been fixed by the commit for bug 411802. The fix will be available in Krita 4.3.1. *** This bug has been marked as a duplicate of bug 411802 ***