https://bugs.kde.org/show_bug.cgi?id=490358
--- Comment #16 from Michael Marley <mich...@michaelmarley.com> --- I've done quite a bit more testing and I have made some interesting and hopefully-relevant findings. After determining that raising the safetyMargin to 15003ms eliminated most of the frame drops, I then attempted to restore the latency configuration that was removed in https://invent.kde.org/plasma/kwin/-/merge_requests/4408 with an additional default option "Automatic" to use the current behavior. I did that successfully (including proving that the expectedCompositingTime values were actually getting set as intended). However, I found that had absolutely no effect on the frame drops, so I further modified it to set an expectedCompositingTime so high that it would effectively force it to start rendering the next as soon as the previous had been displayed. That also had no effect. I then realized that safetyMargin is also used in drm_commit_thread.cpp independently of its use in renderloop.cpp. Upon determining that, I changed renderloop.cpp to hardcode an addition of 1500us instead of using safetyMargin and then set the safetyMargin to 15003us again. This has very similar or the same behavior to the previous test where I only set safetyMargin to 15003us without hardcoding the old value in renderloop.cpp, indicating that the framedrops I am seeing are causing by something in drm_commit_thread.cpp. I'm not well-versed enough with the code to understand the implications of that, however. -- You are receiving this mail because: You are watching all bug changes.
