Created attachment 162728 [details] Canvas Settings and Example Recording Video SUMMARY During recording with the new 10 Hz feature we had an issue with a medium sized canvas and a big brush. The raw PNGs, which where exported, are only correct as long as we use a small size brush. As soon as we enlarge the size (we used the Basic-5 Size brush with >500px, but it seems to be independent of the used brush as long as it is big enough), several of the exported PNGs are white. And the complete build up of the colored area was not captured. The colored area just appears from one frame to the next (please also see the attached Show Case video). We didn't observe any LowPerformance warnings. STEPS TO REPRODUCE 1. Open a canvas 2000x2000 pixels and with a resolution of 300 (for additional details see the attached Screenshot) 2. Start the recording of the Docker Recoder Plugin with a Capturing Interval of 0.1 sec 3. Select a big brush with at least 500px 4. Build up a big colored area with your brush. Do this really fast. Probably, it is a performance issue and therefore you must force the system into a little bit of work. OBSERVED RESULT We observed the bug only on the high performance system of my wife. I can imagine, that this has something todo with the LowPerformanceWarnings. On my old system, I get all the time such warnings with the same setup. But not so on my wifes system. The reson is probably, that on my system the capturing is not taken every 100ms, becaus it is just to slow. And this could also explain, why I don't get the same bug. EXPECTED RESULT Every 100 ms the current canvas should be exported as it is, without any white frames or missing frames. SOFTWARE/OS VERSIONS Windows 11: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I'm currently working on an additional Real Time Capture Mode for the Docker Plugin, which is almost ready for a merge request (https://invent.kde.org/freiser/krita-freiser/-/tree/freiser/RecorderRealTimeMT?ref_type=heads). Hence, I have a complete Krita development environment setup here. And I have dug a little bit into the Docker Recorder code, already. I'm pretty sure, that this bug is to advanced for my Krita knowledge, I have so far :-) But I'm willing to support you as much as I can, finding this nasty bug. We are heavly depending on this feature to hold our deadline. Hence, we have a big interest in fixing this as soon as possible. Thank you in advance for your support. Florian
Hi, I've digged a little bit deeper and I fear, this seems to be a hard one. I'm not quite sure what issues this bug, but I have an educated guess. In the `recorder_writer.cpp`, the data of the current image is read into an internal buffer https://invent.kde.org/graphics/krita/-/blob/master/plugins/dockers/recorder/recorder_writer.cpp?ref_type=heads#L135 Due to the fact, that I only see the bug on a high performance system, where we really can hold the 10Hz capturing, in combination with the usage of big brushes (which means, Krita has something to do updating the canvas and therefore writing continously the internal data), my guess is, that we have maybe a race condition somewhere in the internals of the Krita data managment. I debugged a little bit this morning and found myself in the `KisTiledDataManager`. But the corresponding read operation is locked by a Read Mutex: https://invent.kde.org/graphics/krita/-/blob/master/libs/image/tiles3/kis_tiled_data_manager.cc?ref_type=heads#L699 So, maybe I'm on the totally wrong position. But maybe not. Could it be, that we keep the Datamanger so busy in reading data, that we do not release the mutex often enough? Maybe, its internal data can not be updated anymore? But to give an anwser to this question, I have not enough epxerience with Krita. Do you have any ideas, where we could add traces in the code to track down this nasty little beast? Florian
Hi, I've found a workaround for this bug. Just go to Krita Menu -> Settings -> Configure Krita -> Display -> Canvas Acceleration The Canvas Acceleration must be switched on. If you use "Auto" on Windows, most probably your system has chosen Direct3D. On some systems, this could lower the performance. See also https://docs.krita.org/en/reference_manual/preferences/display_settings.html: > ANGLE Direct3D (Windows Only) > Krita will use the ANGLE compatibility layer to convert the OpenGL calls to Direct3D calls. > Whether this works better than regular OpenGL depends on the graphics drivers of the computer. But the most effective setting to workaround this bug is to reduce the quality of the Scaling Mode. On my system, it was already enough to switch the value from "High Quality Filtering" to "Trilinear Filtering". But reduce it even more, if you still encounter the bug. Florian
We havehltiple reports for this on KA so let us re open this and solve it