Lots of people have been asking us when we're releasing Zed on Windows. The Windows port started as a one-person project, but for the past 6 weeks, we've had a group of four engineers focused on Windows full-time. We're excited about the progress we're making and want to share an update about the work we're doing.
When we first got Zed running on Windows, we used the same rendering backend we use on Linux, which is based on Vulkan graphics API. It was useful to be able to reuse code between platforms, but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency.
To solve this problem, we created a new rendering backend for Zed based on DirectX 11. DirectX 11 is guaranteed to be available on Windows 7 or later, including Windows VMs, so now Zed should run for the vast majority of Windows users. The new backend also significantly reduces Zed's memory footprint.
Previously, we had two implementations of our GPU shaders: one MSL implementation for macOS, and one WGSL implementation for Vulkan. To use DirectX 11, we had to create a third implementation in HLSL. The process of debugging the new rendering pipeline and shaders led us down an interesting rabbit hole of its own: glyph rasterization.
When developing Zed's original macOS renderer, we had relied heavily on Xcode’s Metal debugger. It lets you capture a frame in your app, step through every draw call that happened in that frame, and inspect every vertex in the scene's geometry, and every pixel in the rendered image.
On Windows, the best comparable tool for graphics debugging is RenderDoc. Unfortunately, Zed crashed on startup when run under RenderDoc, because we were relying on the Direct2D API for text rendering, and RenderDoc does not support applications that use Direct2D. To work around this limitation, we decided to stop using Direct2D and switch to rasterizing glyphs using DirectWrite instead. In the process, we fixed bugs where glyphs' boundaries were not calculated correctly, which had been causing incorrect clipping for certain characters and font sizes.
Inspecting Zed's rendering using RenderDoc. Here we're viewing the glyph atlas—a GPU texture that contains one copy of every glyph in the frame
As more of the Zed team began to use Zed on Windows as our daily driver, some people experienced crashes due to GPU memory allocation failures. Zed seemed to be using GPU memory inefficiently in certain situations. We hadn't noticed this on macOS because recent Macs have unified memory. But on most computers running Windows and Linux, GPUs have separate memory that is more limited.
Luckily, we got help on this problem from the team behind Longbridge, who use Zed's UI framework for their own desktop app. They discovered an inefficiency in our approach to rendering paths - combinations of lines and curves that you can use to draw arbitrary shapes. We use paths in Zed for rendering selections and text highlights.
To create smooth edges for paths, we use multi-sample antialiasing (MSAA)—we draw paths to an intermediate texture with multiple color samples per pixel, and then we copy the averaged pixel values to the final render target. Previously, we were arranging paths in our MSAA textures similarly to how we arrange glyphs in our texture atlas—we allocated enough space in the textures to place each visible path without overlap. This sometimes resulted in us allocating a lot of very large textures.
The Longbridge folks landed an initial fix for this problem that removed the intermediate textures entirely, and enabled MSAA for our entire scene. Unfortunately, this ended up tanking performance on Intel GPUs, which have less efficient implementations of MSAA. But we found another approach to MSAA that avoided the high VRAM usage: we now draw all paths to a single color MSAA texture that's the same size as our render target, allowing the paths to overlap as they do in the final scene. We then copy directly from this texture to the render target. This change fixed the high VRAM usage, and also improved Zed's rendering performance on all platforms, even macOS.
Using RenderDoc to inspect the draw call where paths are copied from an intermediate MSAA texture into the final scene
Graphics isn't the only thing that's different on Windows; there are also unique restrictions on file system operations. In particular, you can't overwrite an .exe file while it's running. This meant we needed a new strategy for performing auto-updates. On macOS and Linux, we simply copy the new application bundle into place, overwriting the old one, after downloading an update. But on Windows, we must perform this step when Zed.exe is not running.
After a few iterations, we've settled on an approach where we use a dedicated "auto update helper" binary that gets invoked on quitting or restarting Zed. The auto update helper finishes moving executables into place, and then restarts Zed if needed.
Even crashing is different on Windows! We had to rework our crash reporting infrastructure, because on Windows, symbolicating stack traces requires a .pdb file that is too large to ship to users as part of the installer. For users who allow it, we now collect minidump files to help us track and debug the crashes that users are experiencing, and symbolicate these crashes server-side after they are uploaded.
There are still problems to solve before we declare Zed on Windows ready for general use. Here are the areas we're focused on in the coming weeks:
- Key bindings - Windows users have different expectations about how key bindings are displayed, and what kinds of keyboard shortcuts will be bound, depending on their keyboard layout.
- SSH Remoting - When editing files on a remote Linux machine from a Windows client, there are currently bugs related to different file-system path conventions. Also, SSH itself works differently on Windows.
- WSL - Though it's currently possible to edit files in the Linux subsystem using a local SSH connection, we're adding first-class support for WSL.
- Extensions - Zed extensions are cross-platform WASM binaries, and have access to standard file system APIs via the WebAssembly System Interface. On Windows, there are some mismatches in path conventions between the extension and host, which we need to account for.
- Performance - We'll be keeping an eye on the performance of our new graphics backend, and any other OS-specific code paths, to ensure that the Windows app is as snappy as our macOS version.
Related Posts
Check out similar blogs from the Zed team.
Looking for a better editor?
You can try Zed today on macOS, Windows, or Linux. Download now!
We are hiring!
If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.
Instagram Engineering
Shopify Engineering