Bug 486417

Summary: Canvas turns black when background caching animation frames
Product: [Applications] krita Reporter: Ralek Kolemios <info>
Component: AnimationAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: dimula73, emmetoneill.pdx
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Black screen when scrubbing or playing

Description Ralek Kolemios 2024-05-01 21:08:00 UTC
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.
Comment 1 Ralek Kolemios 2024-05-07 18:49:35 UTC
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.
Comment 2 Ralek Kolemios 2024-05-07 18:55:57 UTC
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,
Comment 3 Ralek Kolemios 2024-08-01 20:00:01 UTC
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
Comment 4 Dmitry Kazakov 2024-08-02 12:18:24 UTC
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
Comment 5 Dmitry Kazakov 2024-08-02 12:40:20 UTC
Hi, Ralek!

Could you please share a video recording of the original bug? I cannot reproduce it it seems :(
Comment 6 Ralek Kolemios 2024-08-02 19:40:09 UTC
Created attachment 172229 [details]
Black screen when scrubbing or playing

Heya! Thanks for checking. I've attached a video of the problem
Comment 7 Dmitry Kazakov 2024-08-05 13:33:53 UTC
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
Comment 8 Dmitry Kazakov 2024-08-05 13:34:02 UTC
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
Comment 9 Dmitry Kazakov 2024-08-05 13:34:55 UTC
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
Comment 10 Dmitry Kazakov 2024-08-05 13:35:04 UTC
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
Comment 11 Dmitry Kazakov 2024-08-06 13:30:41 UTC
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
Comment 12 Dmitry Kazakov 2024-08-06 13:32:13 UTC
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
Comment 13 Dmitry Kazakov 2024-08-21 12:27:32 UTC
*** Bug 459134 has been marked as a duplicate of this bug. ***