https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #8 from [email protected] --- I've been doing some debugging by instrumenting kwin to emit some CSV events for `window->resourceClass().compare(QStringLiteral("chromium-browser"))` clients, and I think I understand the reason now. When there's a client like glxgears, rendering at full vsync rate, there's basically always a pending frame in KWin. Specifically: `RenderLoopPrivate::pendingFrameCount` is consistently 1 by the time my chromium-browser reports damage to KWin. So it has to go through the delayScheduleRepaint() route, which means getting shown two pageflips from now, not the next one. I patched my local KWin to cap expectedCompositingTime at 6ms. This way, I was able to get my min & median measurements to ~match idle KWin, without glxgears running. But with a 6ms cap, it still hit the pendingFrameCount==1 case about 27% of the time, so the latency tail is still there. Going any lower with the cap caused missed frames, so I'm glad KWin is being conservative by default. I'll keep digging, maybe I can narrow it down. It feels like there's plenty of time for glxgears to co-exist with another app without causing these effects. Max render time is like 3ms, so I think the variability is coming from another source, not actual compositing. -- You are receiving this mail because: You are watching all bug changes.
