https://bugs.kde.org/show_bug.cgi?id=476326
--- Comment #1 from Florian Reiser <reise...@gmail.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.
