When animating, scrolling through the timeline quickly or pressing play will turn the canvas black. The canvas cannot be restored unless the document is reopened, or graphics acceleration is turned off. To reproduce: Open a new document, create three blank keyframes, scrub through them quickly or press play. Things of note: - If canvas acceleration is off, this does not occur - If 'enable background cache generation' is off, this only occurs when pressing play and not when scrubbing.
This bug doesn't seem to occur with the same system settings, preferences, and hardware when run inside of the Krita docker. Here are the differences between the buggy install and the docker: Docker: Ubuntu 20.04.6 LTS Vendor: Mesa/X.org Renderer: llvmpipe (LLVM 12.0.0, 256 bits) Driver Version: 4.5 (Core Profile) Mesa 21.2.6 OpenGL Version: 4.5 Buggy system: Ubuntu 23.10 Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce RTX 4090/PCIe/SSE2 Driver Version: 4.6.0 NVIDIA 535.171.04 OpenGL Version: 4.6 All other components appeared the same or nearly the same.
Scratch that, the bug appears in the docker as well and is directly related to the 'limit cached frame size' both in and out of docker. New bug description: When the max cache frame size is smaller than the canvas size, and opengl is on, scrubbing quickly or pressing play will turn the canvas black until turning canvas acceleration off or reloading the file,
When closing the document affected by this bug, these safe asserts pops up: SAFE ASSERT (krita): "!sanityCheckPointer.isValid()" in file /builds/graphics/krita/libs/ui/KisDocument.cpp, line 706 SAFE ASSERT (krita): "cache" in file /builds/graphics/krita/libs/ui/kis_animation_cache_populator.cpp, line 129
I have tested on Windows. I can reproduce the asserts on exit, but I cannot reproduce the actual black-canvas issue. I'll check on Linux now
Hi, Ralek! Could you please share a video recording of the original bug? I cannot reproduce it it seems :(
Created attachment 172229 [details] Black screen when scrubbing or playing Heya! Thanks for checking. I've attached a video of the problem
Git commit 813ce2685dd92f1587684ef702493f0d314818d8 by Dmitry Kazakov. Committed on 05/08/2024 at 13:33. Pushed by dkazakov into branch 'master'. Fix asserts on exiting Krita with animated image open The patch fixes two issues: 1) We should store a weak pointer to KisImage to avoid leaking of the image data after it has been destructed. 2) It may happen that the populator decides to regenerate the cache when all its view has already been destroyed, but the image itself not. In this case we should just ignore such "priority requests" . M +32 -2 libs/ui/kis_animation_cache_populator.cpp https://invent.kde.org/graphics/krita/-/commit/813ce2685dd92f1587684ef702493f0d314818d8
Git commit 447f962df334f9684aae2f1a03f382144b4c7f76 by Dmitry Kazakov. Committed on 05/08/2024 at 13:33. Pushed by dkazakov into branch 'master'. Don't priority-recalculate frames when they are already cached Priority frames get inserted in the list when the user scratches the animation timeline. It might happen that the frame will get cached before the populator wakes up, so there is no use in recalculating them again. M +7 -0 libs/ui/kis_animation_cache_populator.cpp https://invent.kde.org/graphics/krita/-/commit/447f962df334f9684aae2f1a03f382144b4c7f76
Git commit 918379a953a1d630939931ee8910143a42df96ec by Dmitry Kazakov. Committed on 05/08/2024 at 13:34. Pushed by dkazakov into branch 'krita/5.2'. Fix asserts on exiting Krita with animated image open The patch fixes two issues: 1) We should store a weak pointer to KisImage to avoid leaking of the image data after it has been destructed. 2) It may happen that the populator decides to regenerate the cache when all its view has already been destroyed, but the image itself not. In this case we should just ignore such "priority requests" . M +32 -2 libs/ui/kis_animation_cache_populator.cpp https://invent.kde.org/graphics/krita/-/commit/918379a953a1d630939931ee8910143a42df96ec
Git commit 5e141c1fb3e326f962cda81d318ac62156449c73 by Dmitry Kazakov. Committed on 05/08/2024 at 13:34. Pushed by dkazakov into branch 'krita/5.2'. Don't priority-recalculate frames when they are already cached Priority frames get inserted in the list when the user scratches the animation timeline. It might happen that the frame will get cached before the populator wakes up, so there is no use in recalculating them again. M +7 -0 libs/ui/kis_animation_cache_populator.cpp https://invent.kde.org/graphics/krita/-/commit/5e141c1fb3e326f962cda81d318ac62156449c73
Git commit 66e3b37f23554fe73b196ab1f277c661eaa44072 by Dmitry Kazakov. Committed on 06/08/2024 at 13:25. Pushed by dkazakov into branch 'master'. Fix black canvas appearing when "Limit animation frame size" is active The problem happens when "Limit animation frame size" is used in combination with bilinear or nearest-neighbour filtering. In this case the entire mipmap does not get fully initialized, hence the textureLod() and glTexSubImage2D() calls become undefined (the latter actually errors-out). M +20 -5 libs/ui/opengl/kis_texture_tile.cpp M +2 -0 libs/ui/opengl/kis_texture_tile.h https://invent.kde.org/graphics/krita/-/commit/66e3b37f23554fe73b196ab1f277c661eaa44072
Git commit fd78e1552764b845d95c39c9ffb0bcab2c0279a1 by Dmitry Kazakov. Committed on 06/08/2024 at 13:31. Pushed by dkazakov into branch 'krita/5.2'. Fix black canvas appearing when "Limit animation frame size" is active The problem happens when "Limit animation frame size" is used in combination with bilinear or nearest-neighbour filtering. In this case the entire mipmap does not get fully initialized, hence the textureLod() and glTexSubImage2D() calls become undefined (the latter actually errors-out). M +20 -5 libs/ui/opengl/kis_texture_tile.cpp M +2 -0 libs/ui/opengl/kis_texture_tile.h https://invent.kde.org/graphics/krita/-/commit/fd78e1552764b845d95c39c9ffb0bcab2c0279a1
*** Bug 459134 has been marked as a duplicate of this bug. ***