Skip to content

gpui-ce v0.3.3 updates/refactors + performance optimizations#4

Draft
muktidaya wants to merge 10 commits into
mdeand:mainfrom
muktidaya:dev
Draft

gpui-ce v0.3.3 updates/refactors + performance optimizations#4
muktidaya wants to merge 10 commits into
mdeand:mainfrom
muktidaya:dev

Conversation

@muktidaya

@muktidaya muktidaya commented Apr 7, 2026

Copy link
Copy Markdown

Re-request of #3 due to changes to my downstream fork from which the diff is provided.

It was observed while running a small application that implements gpui-wgpu with basic
text editing and filesystem features that idle CPU and GPU usage sat at ~45% and ~35% respectively on an M2 MacBook Air. This was discovered to be the result of draw requests being fired at every event loop tick, which is the display refresh rate if not otherwise specified. Thus, this PR replaces the naïve window redraw request loop originally implemented as part of PR #2 with a conditional redraw request method that waits on GPU update, OS, and WakeUp events before firing.

Additionally, a BackgroundExecutor was implemented which provides a public wake() method that provides an interface for background threads (such as a tokio runtime) to the Dispatcher that fires WakeUp events and requests redraws.

These changes and additions brought the aforementioned idle CPU and GPU usage down to an observed ~0%.

Please feel free to tweak to taste. :3

muktidaya and others added 10 commits March 25, 2026 13:01
Ensures all windows are repainted after draining the main queue,
preventing potential stale frame issues when the application wakes up.
The event loop ran with ControlFlow::Poll and unconditionally called
request_redraw() in about_to_wait(), causing the GPU to re-present the
same frame at display refresh rate (~60-120 fps) even when nothing had
changed. require_presentation: true compounded this by ensuring present()
was called every frame, which fired SurfacePresent -> request_redraw() in
a self-sustaining loop.

Switch to ControlFlow::Wait and remove the unconditional request_redraw()
from about_to_wait(). Rendering is now driven by three sources: WakeUp
events (sent by external threads via BackgroundExecutor::wake()), the
SurfacePresent chain (for consecutive dirty frames), and OS events that
flow through cx.notify() -> dispatcher -> WakeUp.

Expose BackgroundExecutor::wake() so callers outside gpui (e.g. a tokio
watch-channel task) can signal the event loop when new data is ready
without polling.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ontrolFlow::Wait

Same-thread event processing (mouse scroll, keyboard, clicks) can dirty
a window via cx.notify() → invalidate_view, but nothing called
request_redraw() afterwards. Under ControlFlow::Wait the event loop
sleeps, so the dirty frame was never rendered.

Add a request_redraw() call after every window_event dispatch. The
on_request_frame handler already gates real work on is_dirty(), so
this is a no-op when nothing actually changed — idle CPU stays near 0%.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace StdRng::clone() with StdRng::from_rng() in TestDispatcher::rng,
  as rand 0.10 removed Clone from StdRng
- Add required depth_slice and multiview_mask fields to wgpu
  RenderPassDescriptor in the wgpu_surface example

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ream consumers of the library:

- Add #[allow(dead_code)] to in-progress wgpu rendering infrastructure
  (VERTEX_ATTRIBUTES constants, bind-group structs, unused fields/methods)
  that is defined but not yet wired into the active rendering path
- Replace overly-narrow cfg_attr on PlatformInputHandler with a plain
  #[allow(dead_code)], since its methods are platform-specific (x11/wayland)
  and legitimately unused on macOS builds
- Fix irrefutable `if let SurfaceContent::Wgpu` pattern → `let` binding,
  removing the now-orphaned closing brace
- Delete empty after_frame() method that had a TODO questioning its existence
- Prefix unused `cx` and `depth_view` variables with `_` in wgpu_surface example
Sync with gpui-ce upstream (de080b0 "Re-re-fork (gpui-ce#23)"):

- Add scheduler module with Priority, Scheduler trait, TestScheduler,
  and executor types for task scheduling and timing
- Add PlatformScheduler bridging PlatformDispatcher to Scheduler trait
- Replace executor.rs to delegate to scheduler types instead of using
  PlatformDispatcher directly
- Rename gpui_macros -> gpui_ce_macros as local workspace crate in
  tooling/macros/
- Simplify RunnableVariant from enum to type alias
- Update PlatformDispatcher trait (remove label param, RealtimePriority)
- Fix queue.rs: probability() -> weight(), Realtime -> RealtimeAudio
- Reorganize: fonts to resources/, scripts to scripts/, license update
- Add workspace declaration to Cargo.toml with tooling/macros member

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add missing `type Result<T> = T` to AppContext derive impl
- Remove `type Result<T>` from VisualContext derive impl (it belongs to AppContext)
- Fix `Window::focus` call passing a spurious second argument
- Declare `rust_analyzer` as a known cfg in Cargo.toml to suppress unexpected_cfgs warning

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
RedrawRequested is a WindowEvent in winit 0.30+. The unconditional
request_redraw() added at the end of window_event by fad7c07 caused
every RedrawRequested to immediately queue another, so the event loop
never slept under ControlFlow::Wait — recreating the spin loop that
a2ed2da had fixed.

Return early after invoking on_request_frame so RedrawRequested does not
chain itself. All other window events (input, focus, resize, etc.) still
fall through to request_redraw() as intended.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

@muktidaya muktidaya left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lot's of (rough WIP) work to bring the repo current with gpui-ce v0.3.3.

Admittedly I've found myself obsessively working on this to the point that this is approaching too much for a single PR.

@muktidaya muktidaya changed the title Re-equest of PR #3 gpui-ce v0.3.3 upates/refactors + performance optimizations Apr 7, 2026
@muktidaya muktidaya changed the title gpui-ce v0.3.3 upates/refactors + performance optimizations gpui-ce v0.3.3 updates/refactors + performance optimizations Apr 7, 2026
@mdeand mdeand marked this pull request as draft April 18, 2026 01:01
@mdeand

mdeand commented Apr 18, 2026

Copy link
Copy Markdown
Owner

I'll mark this as a draft until further updates, aside from that, looks good so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants