Bug 486417

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. ***