| Summary: | White Frames/Missing Frames during Recording | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Florian Reiser <reiserfm> |
| Component: | Dockers/Recorder | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | halla, raghu, reiserfm |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Canvas Settings and Example Recording Video | ||
|
Description
Florian Reiser
2023-10-30 12:43:33 UTC
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 Is this still relevant? 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |