https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #4 from Zamundaaa <[email protected]> --- > Is it expected that one windowed app redrawing every vblank is going to > negatively impact input latency of other windowed apps? It's more complicated than that (depending on the CPU and GPU, having something updating all the time can reduce latency by increasing clock speeds) but generally, yes, that is expected. 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. > 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. -- You are receiving this mail because: You are watching all bug changes.
