Sometimes the following behavior happens: Painting on or changing visibility of a layer doesn't show anymore. Selecting another layer makes the changes appear while creating a rogue "Move" entry in undo history. Undoing stops working. Trying to undo steps and then paint or change visibility of a layer may either result in the changes added after the last undo step instead of the selected one and the creation of another false "Move" undo entry, or it may force the undoing to take effect and apply the action after the selected undo step as it would normally be expected - when this happens the bug does away for the time being. One time it happened while editing a local selection. This caused the selection to be overwritten, which reflected on its thumbnail, but selecting it still showed the decoration for the state before overwritten. After saving the document and restarting Krita the selection was indeed overwritten just like them thumbnail showed earlier. The triggering of and behavior of this bug seems inconsistent, so far I was unable to identify any patterns or reliable ways to reproduce it, but it happened several times in the past week or so. Saving the document and restarting Krita clears the issue but data loss may happen if we were unable to force undoing to take effect before saving. STEPS TO REPRODUCE Unknown - but probably related to changing visibility of and/or moving layers. Krita Version: 4.2.0-pre-alpha (git 05baa5b) Qt Version (compiled): 5.11.2 Version (loaded): 5.11.2 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.19.4-arch1-1-ARCH Pretty Productname: Arch Linux Product Type: arch Product Version: unknown OpenGL Info Vendor: NVIDIA Corporation Renderer: "GeForce GTX 750 Ti/PCIe/SSE2" Version: "4.6.0 NVIDIA 415.18" Shading language: 4.60 NVIDIA Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.6 Supports deprecated functions true is OpenGL ES: false
Still experiencing this. It also interferes with saving: the document will give a warning that an operation is still in progress, and when I click save regardless, it won't actually save. I have just spent 5 minutes doing all kinds of random things hoping that something makes my document savable. I know this report is not very helpful but I don't know how could I describe it any better.
This keeps occurring but I still didn't find a consistent way of reproducing. But my best guess is that it's either triggered by using selections or by toggling layer visibility, or maybe the combination of the two. I wonder if anyone else experienced this?
Yes, get this, too. There was a bit of discussion here, though off-topic for that ticket: https://bugs.kde.org/show_bug.cgi?id=396509#c12
I have finally found a consistent way to reproduce: Open existing file or make a new, just have two layers and at least one with content. 1; Move layer with Move tool 2; Switch back to Brush tool 3; Select the other layer and try to draw. What happens: The canvas won't update. Toggling layer visibility won't update. Undo won't work. You can't save, add new layer, or perform seve4ral other operations (Popup: Waiting for current operation). 4; Select another layer What happens: Canvas and layers suddenly update, and a bogus "Move" entry is added to history. This keeps happening every time another layer is selected. It can temporarily be fixed by doing this: 1; Toggle the visibility of a layer that is currently invisible and NOT selected (it wont't work) 2; Select the layer you toggled What happens: Canvas and layer updates, you can draw, save, undo, add layer etc. again but only until you select another layer, which will then trigger the bug again.
First bad commit (via git bisect): commit 5f91230f074be53379ba1461c6a1560d1f8aa1eb Author: Boudewijn Rempt <boud@valdyas.org> Date: Wed Nov 28 12:44:43 2018 +0100 add a createActions method to KoToolFactoryBase
I can reproduce this with various recent nightly builds. There's probably other combinations of selecting/layer actions leading to this, but the steps above work every time for me. Krita Version: 4.2.0-pre-alpha (git 52afd0c) Qt Version (compiled): 5.10.0 Version (loaded): 5.10.0 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.9.0-8-amd64 Pretty Productname: Debian GNU/Linux 9 (stretch) Product Type: debian Product Version: 9 OpenGL Info Vendor: Intel Open Source Technology Center Renderer: "Mesa DRI Intel(R) Kabylake GT2 " Version: "3.0 Mesa 13.0.6" Shading language: 1.30 Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(NoProfile)) Version: 3.0 Supports deprecated functions true is OpenGL ES: false
I wonder if this is due to the same commit: Since about the same time I've had frequent segfaults when confirming moves or transformations. I haven't found a reliable set of steps to reproduce, though, but once this issue is fixed I can try again and see if I still get them.
This commit might also be causing this bug: https://bugs.kde.org/show_bug.cgi?id=403048
*** This bug has been marked as a duplicate of bug 403048 ***
It seems that only using the move tool could create this weird state. I've fixed that in https://commits.kde.org/krita/0d2f1d16e187a2110e2bf4b21e0d9c23b0871489