https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #5 from [email protected] --- (In reply to Zamundaaa from comment #4) > If compositing takes more time (because larger parts of the screen need to > be repainted, or the other app takes some of the CPU or GPU time for its own > rendering), it very simply takes more time and latency is increased. I will try to see what my numbers are with KWIN_LOG_PERFORMANCE_DATA=1. This is a 4090 driving a single 4K display. nvtop and CPU looked fully idle but I'll try to get a timeline of CPU & GPU activity - not sure how yet. Maybe I could set up a test environment with an AMD GPU and then use GPUVis. I think that can get me the complete timeline that could be relevant. > > And for mouse movements, I don't think it's caused by the foreground app > > responding and redrawing in response to every mouse input. > You misunderstood, any and all screen changes are queued up and applied with > atomic commits. That includes the cursor position; for every mouse event, up > to like ten atomic test commits are expected (depends on how much is > happening on the rest of the screen, the polling rate of the mouse and the > refresh rate of the screen). > > > I don't think it's as simple as "Zed is always compositing first, and the > > occasional redraw from chromium (the other window, in response to a mouse > > click) gets delayed until the next composited frame" > That's not how compositing works. All windows are composited in one go, and > the result is presented at fixed time intervals (assuming no adaptive sync). > When exactly compositing is started for a given frame depends on how long it > took in past frames. Fair enough, but then 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? I've now done a round of tests with `KWIN_DRM_OVERRIDE_SAFETY_MARGIN=200` and the results are: 1. min=8.7ms median=13.4ms for a static mouse clicker, 21 commits/s Dropping the safety margin decreased this test from the min=13.5ms, median=18.57ms it was in the earlier attachment 2. min=15ms, median=20.4ms for a static mouse with zed open, 120 commits/s 3. min=15ms, median=29.97ms for a circling mouse (zed closed), 120 commits/s This is me just waving the mouse around the test area while the clicker does its captures If compositing is happening at fixed time intervals, where is the extra latency coming from? Is there a queue that gets saturated whenever kwin is compositing at max refresh rate, i.e. commits/s matching refresh rate? Whenever it's below that, like in the tests hitting 4 or 21 commits per second, that's when the latency drops to the lowest I observed. -- You are receiving this mail because: You are watching all bug changes.
