gpui: Park the Wayland frame loop while windows are idle

[phisch]

Objective

GPUI apps on Wayland burn CPU at the display refresh rate while a window is visible (at least partially on an active output), even when nothing changes. The frame callback loop unconditionally re-arms itself: every done requests the next frame callback and ends in a commit, so the compositor wakes us ~60 times (or more on higher refresh rates) per second forever, only to skip drawing.

I noticed this while working on a GPUI application, and found an empty window constantly consuming CPU resources.

Solution

• New PlatformWindow::request_redraw(), a no-op everywhere except Wayland.
• A Wayland frame now only commits (arming the next callback) when something was drawn or another frame is wanted, otherwise the loop parks.
• Windows that still need a frame after an effect flush call request_redraw, which resumes a parked loop with one bare commit. All state changes funnel through the effect flush, so no wake source is missed.
• The gpui_linux: Fix Wayland flickering under CPU load by skipping redundant surface commit #54214 guard (no bare commit on a frame the renderer presented) is preserved. Idle windows now issue zero bare commits instead of 60/s.

Testing

Measured debug build: an idle window went from 62 wakeups/s and ~2% CPU to 0 wakeups and 0% over 20s, WAYLAND_DEBUG shows the protocol going silent. Verified redraw-on-timer (park, wake, redraw, re-park),
continuous animation at full rate.

X11 is unaffected (tested on bspwm), and cargo test -p gpui and script/clippy still pass.

To test: run any gpui example on Wayland and watch CPU in htop (or any other system monitor).

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

---

Release Notes:

• Fixed idle windows waking at the display's refresh rate on Wayland

[iddm]

GPUI apps on Wayland burn CPU at the display refresh rate while a window is visible (at least partially on an active output), even when nothing changes. The frame callback loop unconditionally re-arms itself: every done requests the next frame callback and ends in a commit, so the compositor wakes us ~60 times (or more on higher refresh rates) per second forever, only to skip drawing.

I noticed this while working on a GPUI application, and found an empty window constantly consuming CPU resources.

I found the exact opposite behaviour: when there is nothing to stitch for the compositor, and the Wayland client doesn't draw, the Wayland server does not invoke the app callbacks to draw, and so the drawing freezes completely. So 0 draw callbacks are called; nothing is rendered on the screen. This is why #60690 was created, as well as why I created my PR. Does it work here the same way? Cuz judging by the description, it attempts to solve a different problem.

This behaviour also isn't specific to GPUI and Zed; I ran into it myself when I was also recently creating a game ui in Vulkan and found the exact same issue with Wayland.

[phisch]

@iddm Before diving into anything, have you tested if this PR solves your problem? Compiling and testing is a bit faster than trying to figure out what causes your problem, understanding that problem, and finding out if this approach fixes it by chance.

Please give it a quick test, and let me know which compositor you are experiencing that issue under.

[iddm]

@iddm Before diving into anything, have you tested if this PR solves your problem? Compiling and testing is a bit faster than trying to figure out what causes your problem, understanding that problem, and finding out if this approach fixes it by chance.

Please give it a quick test, and let me know which compositor you are experiencing that issue under.

Yes, I wanted to test it, but didn't have time today, hopefully, tomorrow.

I am on Hyprland.

[phisch]

@iddm Before diving into anything, have you tested if this PR solves your problem? Compiling and testing is a bit faster than trying to figure out what causes your problem, understanding that problem, and finding out if this approach fixes it by chance.
Please give it a quick test, and let me know which compositor you are experiencing that issue under.

Yes, I wanted to test it, but didn't have time today, hopefully, tomorrow.

I am on Hyprland.

Let me know once you had some time to test! Thanks for the help!

[NeelChotai]

Thank you for working on this! Your debug of the issue is spot on; the PR that @iddm referenced tackles the same thing but also gets rid of the bare surface commit: #60690

The difference is whether we rely on compositor wakes or handle that internally, and this PR uses the existing mechanism (the former) but this causes issues on a fullscreen because callbacks only fire when the compositor repaints, and a damageless (i.e. no change) commit on a static surface may never get one.

I've added you as a co-author on #60690, so your contribution will still be reflected. The remaining gaps you identified (broader flush wake, async refresh) are fixed as part of #61063, so we will land one after the other.

However, I'm happy to wait on testing before moving forward in case it turns out we're mistaken about the bufferless commit being the root cause.

[phisch]

@NeelChotai thanks for taking over! 👍

Since @iddm already confirmed (#60690 (comment)) that their problem is resolved in the new PR, we should just go ahead with the merge instead of waiting to see if this now obsolete PR also solves it.

Closing this PR in favor of #60690

[iddm]

@iddm Before diving into anything, have you tested if this PR solves your problem? Compiling and testing is a bit faster than trying to figure out what causes your problem, understanding that problem, and finding out if this approach fixes it by chance.

Please give it a quick test, and let me know which compositor you are experiencing that issue under.

Yes, I wanted to test it, but didn't have time today, hopefully, tomorrow.

I am on Hyprland.

Let me know once you had some time to test! Thanks for the help!

I am sorry for the delay. Legitimately tried to run, but rustc, for some reason, eats out all memory... could not launch it to confirm.