https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #6 from Zamundaaa <[email protected]> --- > why do cursor updates (to the cursor plane?) delay the end to end latency in > an app like chromium? Are those ~10 test commits per mouse event that you > mentioned directly responsible? Do they prevent other apps or the compositor > from getting scheduled on the GPU? Atomic tests take some time, and having many queued up makes KWin intentionally increase latency (up to 3ms) for some time to ensure no frames are dropped. The whole frame scheduling logic necessarily reacts to all kinds of things in this way. Because of some missing driver APIs and terrible schedulers, we cannot possibly keep latency constant under varying loads. > I've now done a round of tests with `KWIN_DRM_OVERRIDE_SAFETY_MARGIN=200` 200us isn't enough to (reliably) prevent frame drops, any tests with that are bound to have problems. > If compositing is happening at fixed time intervals, where is the extra > latency coming from? It doesn't. Images are presented at fixed time intervals, but compositing is a separate step from that. -- You are receiving this mail because: You are watching all bug changes.
