https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #3 from [email protected] --- Created attachment 192260 --> https://bugs.kde.org/attachment.cgi?id=192260&action=edit click to photon latency with a Zed window open vs minimized (In reply to Zamundaaa from comment #2) > The editor is almost certainly just pushing updates to the screen, so KWin > composites them and does atomic commits to present the results. There's no > issue here, none in KWin at least. > > > A similar impact is felt whenever I start to move my mouse > Again, same thing, it's completely normal for that to trigger a lot of > atomic commits. I don't want to mislead or focus on the ioctl counts - as a user, I ultimately don't care about those numbers. Atomic commits seem more like a symptom, but my underlying issue is input lag. Is it expected that one windowed app redrawing every vblank is going to negatively impact input latency of other windowed apps? And for mouse movements, I don't think it's caused by the foreground app responding and redrawing in response to every mouse input. I measured atomic commits on an empty virtual desktop, and it still spikes there all the same. Is it Kwin itself updating the cursor plane in that case? It was surprising to me and I'd like to understand why this happens. Attaching my measurements with the window open vs minimized. The deltas for min & median are less than a frame's worth, so 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". -- You are receiving this mail because: You are watching all bug changes.
