zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
47.22k stars 2.72k forks source link

Excessive display server repaints from missing damage/present regions #15166

Open kennylevinsen opened 1 month ago

kennylevinsen commented 1 month ago

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:

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

fatihaziz commented 1 month ago

anything we could do to reduce or make this issue gone without doing any PR or changes on the zed code?