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:

• Vulkan: The VK_KHR_incremental_present extension provides VkPresentRegionsKHR, an extension to VkPresentInfoKHR
• EGL: EXT_swap_buffers_with_damage provides eglSwapBuffersWithDamageEXT as replacement for eglSwapBuffers.
• Metal: CALayer::setNeedsDisplay (setNeedsDisplayInRect for Obj-C) as a separate path for communicating the need to redraw.

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:

WAYLAND_DEBUG=1 ./path/to/zed-editor 2>&1 | grep damage

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