Max BrunsfeldandJunkui Zhang
4d00d07df1
This is another attempt to solve the same problem as https://github.com/zed-industries/zed/pull/29718, while avoiding the regression on Intel GPUs. ### Background Currently, on main, all paths are first rendered to an intermediate "atlas" texture, similar to what we use for rendering glyphs, but with multi-sample antialiasing enabled. They are then drawn into our actual frame buffer in a separate pass, via the "path sprite" shaders. Notably, the intermediate texture acts as an "atlas" - the paths are laid out in a non-overlapping way, so that each path could be copied to an arbitrary position in the final scene. This non-overlapping approach makes a lot sense for Glyphs (which are frequently re-used in multiple places within a frame, and even across frames), but paths do not have these properties. * we clear the atlas every frame * we rasterize each path separately. there is no deduping. The problem with our current approach is that the path atlas textures can end up using lots of VRAM if the scene contains many paths. This is more of a problem in other apps that use GPUI than it is in Zed, but I do think it's an issue for Zed as well. On Windows, I have hit some crashes related to GPU memory. In https://github.com/zed-industries/zed/pull/29718, @sunli829 simplified path rendering to just draw directly to the frame buffer, and enabled msaa for the whole frame buffer. But apparently this doesn't work well on Intel GPUs because MSAA is slow on those GPUs. So we reverted that PR. ### Solution With this PR, we rasterize paths to an intermediate texture with MSAA. But rather than treating this intermediate texture like an *atlas* (growing it in order to allocate non-overlapping rectangles for every path), we simply use a single fixed-size, color texture that is the same size as thew viewport. In this texture, we rasterize the paths in their final screen position, allowing them to overlap. Then we simply blit them from the resolved texture to the frame buffer. ### To do * [x] Implement for Metal * [x] Implement for Blade * [x] Fix content masking for paths * [x] Fix rendering of partially transparent paths * [x] Verify that this performs well on Intel GPUs (help @notpeter 🙏 ) * [ ] Profile and optimize Release Notes: - N/A --------- Co-authored-by: Junkui Zhang <364772080@qq.com>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.