Created attachment 139400 [details] example file ready to use SUMMARY From KA topic https://krita-artists.org/t/animation-frame-rendering-clones-limit-render-in-failure/25029?u=grum999 Everyone is not able to reproduce problem, I don't know why. But we are at least 2, on 3 different computer, to have the problem. In synthesis, using too much CPU to render some animation generate a "render in failure" STEPS TO REPRODUCE Download attached krita document 1. Using document "as provided" When using 19 to 24 CPU to render animation, it’s systematically in failure after few frames has been rendered. When using 18 or less CPU to render animation, it’s sometimes in failure (it occurs, but it’s not systematically - so harder to reproduce) 2. Delete layers “Blur + Pixelize” and “Halftone test” Rendering with 24CPU is most of time complete. But sometime it stop before the end (598 of 600 frames rendered for example) This case is really hard to reproduce systematically. Using less CPU (4 for example) render is complete. Can’t say it will always work: I just can suppose that frequency of failure might be so low in this configuration that it will practically never occurs 3. Delete layers “Blur + Pixelize” and “No filter” When using 19 to 24 CPU to render animation, it’s in failure after few frames has been rendered When using 18 or less CPU to render animation, it’s sometimes in failure (it occurs, but it’s not systematically - so harder to reproduce) OBSERVED RESULT See explanation in step to reproduce section EXPECTED RESULT Rendering animation should be complete whatever the number of CPU is used SOFTWARE/OS VERSIONS Tested with linux krita-5.0.0-prealpha-c25d2e1-x86_64.appimage and krita-5.0.0-prealpha-949e869-x86_64.appimage And also on windows 10 krita-nightly-x64-5.0.0-prealpha-fc927e67fe ADDITIONAL INFORMATION More information is provided on KA topic: https://krita-artists.org/t/animation-frame-rendering-clones-limit-render-in-failure/25029?u=grum999 Grum999
My poor little 6-core Ryzen 1600 isn't able to adequately triage this bug, but I'm going to confirm this based on the testing and discussion in the KA thread that you linked to. Labeling as release blocker. Thanks again Grumm.
Hi Grum, I've uploaded an AppImage for you to test to my DropBox since the file was too large to upload to BugZilla. For the sake of transparency (or if you wish to build it yourself), you can see the commit history here: https://invent.kde.org/eoinoneill/krita/-/commits/grum Here's the link to the AppImage: https://www.dropbox.com/home/KritaFiles?preview=krita-5.0.0-prealpha-grum-b9b8de2-x86_64.appimage Basically, since I don't have the hardware necessary to reproduce this consistently, I want to know whether or not the above AppImage solves some of the problems you have currently with rendering animations on your machine. If it does, it might help direct me toward a solution to this problem. I think it's also very likely that 438760 is related to this bug, so maybe also test to see if that bug is resolved by this change too. Thanks, Eoin.
(In reply to Eoin O'Neill from comment #2) > Hi Grum, > > I've uploaded an AppImage for you to test to my DropBox since the file was > too large to upload to BugZilla. For the sake of transparency (or if you > wish to build it yourself), you can see the commit history here: > https://invent.kde.org/eoinoneill/krita/-/commits/grum > > Here's the link to the AppImage: > https://www.dropbox.com/home/KritaFiles?preview=krita-5.0.0-prealpha-grum- > b9b8de2-x86_64.appimage > > Basically, since I don't have the hardware necessary to reproduce this > consistently, I want to know whether or not the above AppImage solves some > of the problems you have currently with rendering animations on your > machine. If it does, it might help direct me toward a solution to this > problem. > > I think it's also very likely that 438760 is related to this bug, so maybe > also test to see if that bug is resolved by this change too. > > Thanks, > Eoin. I'm sorry, I must have pasted the wrong link. Here's the real link to the AppImage: https://www.dropbox.com/s/laarm1lqqld73ta/krita-5.0.0-prealpha-grum-b9b8de2-x86_64.appimage?dl=0
(In reply to Eoin O'Neill from comment #3) > I'm sorry, I must have pasted the wrong link. Here's the real link to the > AppImage: > Oh thanks! I've downloaded it. Tomorrow it's saturday, I'll have time to test it :) On my side, I also encountered the problem with my 4CPU laptop. > Rendering the “Halftone test” with the 4 CPU has failed after 412 files… > >Edit: the 4 CPU laptop randomly failed/success to generate all frames (but most of time it successfully finish render) But that's sure the problem doesn't occurs as frequently as with more CPU (only be able to reproduce it once time, but it's so slow on 4CPU that I didn't make as much test as with my workstation) Grum999
(In reply to Eoin O'Neill from comment #3) > I'm sorry, I must have pasted the wrong link. Here's the real link to the > AppImage: > > https://www.dropbox.com/s/laarm1lqqld73ta/krita-5.0.0-prealpha-grum-b9b8de2- > x86_64.appimage?dl=0 I'm not able to reopen any Krita file used for testing (krita crash with "No attribute color space for layer: " ) And also can't reproduce some file case (impossible to use Layer style with this appimage, it crash immediately) So I'll try to create a document directly with this appimage, but I'm not sure to be able to reproduce the same situation. Grum999
Hi Finally I was able to test the commit (I had to build Krita on my side as with the provided appimage it was not possible to open my test files; https://krita-artists.org/t/krita-crash-on-opening-kra-file/25342?u=grum999) The change made with commit didn't change anything; I'm still unable to render most of animation with all CPU. (I have considered that only this commit was important for testing: https://invent.kde.org/eoinoneill/krita/-/commit/b9b8de2dfbafa1a27f566ebed23451a8e1b8b222) Grum999
I see, that confirms that it's not the single reused image but has to do with the cloning process. Thanks for testing that! I'll begin investigating this again sometime this upcoming week.
*** Bug 438760 has been marked as a duplicate of this bug. ***
Git commit 00b8f331260f14792c165298857668446737d918 by Dmitry Kazakov. Committed on 05/07/2021 at 10:39. Pushed by dkazakov into branch 'master'. Fix animation rendering interrupts caused by autosave KisRegenerateFrameStrokeStrategy should not be forgettable when the user wants to render his/her video. M +2 -1 libs/image/kis_image_animation_interface.cpp M +1 -1 libs/image/kis_image_animation_interface.h M +2 -1 libs/image/kis_regenerate_frame_stroke_strategy.cpp M +1 -1 libs/image/kis_regenerate_frame_stroke_strategy.h M +3 -3 libs/image/tests/kis_image_animation_interface_test.cpp M +4 -4 libs/ui/KisAsyncAnimationRendererBase.cpp M +13 -2 libs/ui/KisAsyncAnimationRendererBase.h M +1 -1 libs/ui/kis_animation_cache_populator.cpp https://invent.kde.org/graphics/krita/commit/00b8f331260f14792c165298857668446737d918
Ooops sorry Not on the right tab, I reopened the wrong bug ^_^' I put it back to RESOLVED :) Grum999
Git commit 2d9a0878a2ea35c0708f91f38ed8a3075735cd4c by Dmitry Kazakov. Committed on 07/07/2021 at 08:29. Pushed by dkazakov into branch 'master'. Add a (hidden) config option to increase frame rendering timeout If you see random failures while rendering frames for huge images, just open kritarc file and add the following option: frameRenderingTimeout=60000 Where '60000' is the timeout in milliseconds. The default value is 30 seconds and it seems like it is too small for some weird usecases. CC:kimageshop@kde.org M +11 -0 libs/image/kis_image_config.cpp M +3 -0 libs/image/kis_image_config.h M +6 -3 libs/ui/KisAsyncAnimationRendererBase.cpp https://invent.kde.org/graphics/krita/commit/2d9a0878a2ea35c0708f91f38ed8a3075735cd4c
Git commit d566668edd016870ac294a8f8c79c0a10fceee1a by Dmitry Kazakov. Committed on 07/07/2021 at 11:37. Pushed by dkazakov into branch 'krita/5.0'. Add a (hidden) config option to increase frame rendering timeout If you see random failures while rendering frames for huge images, just open kritarc file and add the following option: frameRenderingTimeout=60000 Where '60000' is the timeout in milliseconds. The default value is 30 seconds and it seems like it is too small for some weird usecases. CC:kimageshop@kde.org M +11 -0 libs/image/kis_image_config.cpp M +3 -0 libs/image/kis_image_config.h M +6 -3 libs/ui/KisAsyncAnimationRendererBase.cpp https://invent.kde.org/graphics/krita/commit/d566668edd016870ac294a8f8c79c0a10fceee1a
I confirm that option "frameRenderingTimeout" fixed the problem :) Grum999