Excessive display server repaints from missing damage/present regions #15166
Labels
defect
[core label]
gpui
GPUI rendering framework support
linux
macOS
Platform-specific feedback for macOS behaviors, features, design, etc
performance
Feedback for performance issues, speed, memory usage, etc
When zed draws/presents a window, it uses full damage/no present regions, causing the display server to repaint the entire window on every single paint. This wastes significant GPU resources and power, as this is not just a copy.
Damage/present regions specify which portion of an application surface/layer/window is invalidated and needs to be redrawn by the display server from their latest presented image/buffer. How to do this depends on the platform API used:
VkPresentInfoKHR
eglSwapBuffers
.For Wayland on Linux, the Mesa Vulkan WSI is used through a vendored blade crate, which would rely on
VkPresentRegionsKHR
to submit Wayland damage.Zed will also need to track which regions it has changed. The most important area for fine-grained damage reporting is of course cursor and buffer updates which affect very few pixels at a time, and are also relatively easy to track. When fine-grained tracking is not possible, coarse tracking erring on the side of too much damage should be the next goal, with full surface damage being the fallback for scenarios where it's too hard to track (or too rare a scenario to matter).
Damage reporting is relatively easy to inspect on Wayland by looking at the protocol messages:
However, all platforms should benefit from damage tracking, especially if the display server performs color management, HDR mapping or high detail blending in FP16 intermediate buffers.
Environment
Zed: v0.145.1 (Zed)
OS: Linux Wayland arch unknown
Memory: 61.5 GiB
Architecture: x86_64
The text was updated successfully, but these errors were encountered: