9 ms·

Zed for Windows: What's Taking So Long?

88 points by janjones 1y ago

delta_p_delta_x 1y ago
As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, released with Vulkan 1.3. I suspect targeting Vulkan 1.1 or 1.2 might've been a little more straightforward than... rewriting everything to target DX11. Large games with custom engines (RDR2, Doom, Doom Eternal) were shipped before this was main-lined into Vulkan. But thinking about it a little more, I suspect switching out the back-end to a dynamic rendering-esque one (which is why D3D11 rather than D3D12) was easier than reverting their Rust code to pre-dynamic rendering Vulkan CPU calls; the Rust code changes are comparatively light and the biggest change is the shader. That being said, it's a bit annoying to manually write render-passes and subpasses, but it's not the worst thing, and more importantly extremely high performance is less critical here, as Zed is rendering text, not shading billions of triangles. The singular shader is also not necessarily the most complex[2]; a lot of it is window-clipping which Windows does for free. > 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. I wonder why HLSL wasn't adopted from the outset, given roughly 99.999% of shaders—which are mostly shipped with video games, which mostly target Windows—are written in HLSL, and then use dxc to target SPIR-V? HLSL is widely considered the best-specified, most feature-complete, and most documented shader language. I'm writing a Vulkan engine on Windows and Linux, and I only use HLSL. Additionally Vulkan runs on macOS with MoltenVK (and now 'KosmicKrisp'), but I suppose the Zed spirit is 'platform-native and nothing else'. > symbolicating stack traces requires a .pdb file that is too large to ship to users as part of the installer. Perhaps publishing a symbol server[3] is a good idea here, rather than users shipping dump files which may contain personally-identifiable information; users can then use WinDbg or Visual Studio to debug the release-mode Zed at their leisure. [1]: https://github.com/zed-industries/zed/issues/35205 https://github.com/zed-industries/zed/issues/35205 [2]: https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8bd5dfe5d43972bc8de768ca6/crates/gpui/src/platform/windows/shaders.hlsl https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8b... [3]: https://randomascii.wordpress.com/2020/03/14/creating-a-public-symbol-server-easily/ https://randomascii.wordpress.com/2020/03/14/creating-a-publ...
- andrewmcwatters 1y ago
  Yeah, I maintain a Vulkan backend, and this immediately triggered my internal "what?" alarm. Modern Direct3D is almost indistinguishable from Vulkan, on the other hand. So it shouldn't be difficult for them to add. I also agree with your HLSL comment. It sounds like these guys don’t have much prior graphics or game development experience.
  - delta_p_delta_x 1y ago
    I'd been thinking about it, and I added another paragraph above. I get a feeling they've been targeting Vulkan 1.3 with dynamic rendering from the beginning, so porting to D3D12 would be roughly as complex as rewriting to target older Vulkan.
- maxbrunsfeld 1y ago
  The Zed spirit is definitely to prefer a platform native solution. You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly. Good point that we should publish a symbol server.
  - jamienicol 1y ago
    Did you consider using wgpu instead of writing a new dx11 renderer? It has metal, vulkan and dx12 backends so could have been used for a single renderer for macOS windows and Linux. (And webgpu in the future)
  - bsder 1y ago
    > But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Except that everything has effectively converged to HLSL (via Slang which is effectively HLSL++) and SPIR-V (coming via Shader 7). So, your pipelines, shader language, and IR code would all look mostly the same between Windows and Linux if you threw in with DX12 (which looks much more like Vulkan) rather than DX11. And you'd get the ability to multi-thread through the GPU subsystem via DX12/Vulkan. And, to be fair, we've seen that MoltenVK gets you about 80-90% of native Metal performance on macOS, so you wouldn't have to maintain a Metal backend, anymore. And you'd gain the ability to use all the standard GPU debugging tools from Microsoft, nVidia, and AMD rather than just RenderDoc. You'd abandon this all for some mythical future compatibility with WebGPU--which has deployment counts you can measure with a thimble?
RattlesnakeJake 1y ago
Entirely unrelated, but the sections, toolbars, and controls in that RenderDoc app are so cleanly separated compared to modern dev tools. I wish more apps still looked like this.
- jbverschoor 1y ago
  I have my macOS set up that all buttons have borders etc If I switch no vanilla macOS, it’s basically unusable Clean, but unusable
mxhwll 1y ago
This is why you don’t make your own cross platform toolkit.
- andsoitis 1y ago
  while I would agree in general, there could theoretically be SOME applications where the range of UI controls (and systems) is small enough where it could pay off. But things tend to expand in surface area... So with that, this presents a HUGE opportunity for someone to build something akin to Zed, but not with the baggage that their technical strategy brings.
  - cosmic_cheese 1y ago
    > So with that, this presents a HUGE opportunity for someone to build something akin to Zed, but not with the baggage that their technical strategy brings. Not sure it’s so clean-cut. More than avoiding baggage, you’re just shifting it elsewhere. The question is if you want to own (and can handle) the baggage and benefit from the control that brings.
- WD-42 1y ago
  You'd rather see another crappy, slow editor packaging an entire browser? Because that seems like what people are using for "cross platform toolkits" these days. I'm glad Zed is being ambitious, it's truly a joy to use because it feels native. And to be honest, it's Windows, who cares. If you are a developer you should have switched to Linux years ago anyway.
  - steve_adams_86 1y ago
    No, there are good reasons developers are on Windows. Industrial and embedded systems are very often Windows-based, for better or worse. Heaps of games are developed on Windows. Windows-based software itself is developed on Windows.
    - com2kid 1y ago
Thaxll 1y ago
Why dx11 and not 12? No one should care about win7 in 2025.
- Analemma_ 1y ago
  Think about the customer base: the sorts of users who want a high-performance text editor are exactly the kind of people who will run Windows 7 until it's pried from their cold, dead fingers, and who will flood the support forums with complaints if you limit support to operating systems released in the last 15 years. Because of their target market, Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
  - delta_p_delta_x 1y ago
    > Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter. This is incongruous given Zed uses modern frameworks (which is why they moved to D3D11 from Vulkan in the first place). If Zed really wanted to target 'old Windows' then they might have used Win32 and GDI+, not D3D11. In fact they could've stuck to D2D (which was released with Windows 7 and back-ported to Vista), and not used their own rendering at all, since D2D is already a GPU-accelerated text-rendering API, and then used Win32 windowing primitives for everything else.
  - Someone 1y ago
    Similarly, the Mac version is for MacOS 10.15 (from 2019) or later, and has an x64 version.
    - zamadatix 1y ago
      Zed had already targeted macOS when 10.15 still had over a year of support left https://github.com/zed-industries/zed/commit/b400449a58507cca1fa007197929c2cfd6beabbe https://github.com/zed-industries/zed/commit/b400449a58507cc... and some variant of x86-64 macOS will still be supported through 2028. Neither of these were adding support for really old things, one is current for many years to come and just there hasn't been a reason to break 10.15 support yet so why bother. Meanwhile Windows 7 is already over 2 years past the end of extra-extended support at the time this new code was written with Windows 7 support still in mind. Which is nice, but a very different scenario.
guluarte 1y ago
[flagged]
- CharlesW 1y ago
  Add `—dangerously-skip-permissions` so you can sleep.
dang 1y ago
Related ongoing threads: Zedless: Zed fork focused on privacy and being local-first - https://news.ycombinator.com/item?id=44964916 https://news.ycombinator.com/item?id=44964916 Sequoia backs Zed - https://news.ycombinator.com/item?id=44961172 https://news.ycombinator.com/item?id=44961172
munchler 1y ago
I’m sure this is a dumb question, but why does a code editor need to render on the GPU like a video game? Is it just for niceties like smooth scrolling?
- delta_p_delta_x 1y ago
  > but why does a code editor need to render on the GPU like a video game? It isn't just text editors—nowadays, everything renders on your GPU, even your desktop and terminal (unless you're on a tty). For example, at the bottom of Chromium, Electron, and Avalonia's graphics stack is Skia, which is a cross-platform GPU-accelerated windowing and 2D graphics library. GPU compositing is what allows transparency, glass effects, shadowing, and it makes actually writing these programs much easier, as everything is the same interface and uses the same rendering pipeline as everything else. A window in front of another, or a window partially outside the display? No big deal, just set the 3D coordinates, width, and height correctly for each window, and the GPU will do hidden-surface removal and viewing frustum clipping automatically and for free, no need for any sorting. Want a 'preview' of the live contents of each window in a task bar or during Alt-Tab, like on Windows 7? No problem, render each window to a texture and sample it in the taskbar panels' smaller viewports. Want to scale or otherwise squeeze/manipulate the contents of each window during minimise/maximise, like macOS does? Easy, write a shader. This was a big deal in the early 2000s when GPUs finally had enough raw compute to always run everything, and basically every single OS and compositor switched to GPU rendering roughly in the same timeline—Quartz Extreme on Mac OS X, DWM.exe on Windows, and Linux's variety of compositors, including KWin, Compiz, and more. There's a reason OSs from that time frame had so many glassy, funky effects—this was primarily to show off just how advanced their GPU-powered compositors were, and this was also a big reason why Windows Vista fell so hard on its face—its compositor was especially hard on the scrawny integrated GPUs of the time, enough that two themes—Aero Basic, and Aero Glass—had to be released for different GPUs.
  - munchler 1y ago
    Thanks. That explains why OSs use the GPU for rendering windows and effects, but it's still not clear to me why a code editor would do the same. The features you list (transparency, glass effects, shadowing, window management, etc.) seem to be outside the purview of a text editor. If you're saying that Zed is built on something like Skia, then it would already be cross-platform and not have to worry about Vulkan vs. DirectX, right?
spapas82 1y ago
For people that use scoop and want to try Zed there's a precompiled binary they can install using scoop install zed. I tried it and the experience (mainly visually, fonts colours etc) wasn't very good so I can understand why the Zed developers are reluctant to formally release windows binaries.

88 points by janjones 1y ago

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, released with Vulkan 1.3. I suspect targeting Vulkan 1.1 or 1.2 might've been a little more straightforward than... rewriting everything to target DX11. Large games with custom engines (RDR2, Doom, Doom Eternal) were shipped before this was main-lined into Vulkan. But thinking about it a little more, I suspect switching out the back-end to a dynamic rendering-esque one (which is why D3D11 rather than D3D12) was easier than reverting their Rust code to pre-dynamic rendering Vulkan CPU calls; the Rust code changes are comparatively light and the biggest change is the shader. That being said, it's a bit annoying to manually write render-passes and subpasses, but it's not the worst thing, and more importantly extremely high performance is less critical here, as Zed is rendering text, not shading billions of triangles. The singular shader is also not necessarily the most complex[2]; a lot of it is window-clipping which Windows does for free. > 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. I wonder why HLSL wasn't adopted from the outset, given roughly 99.999% of shaders—which are mostly shipped with video games, which mostly target Windows—are written in HLSL, and then use dxc to target SPIR-V? HLSL is widely considered the best-specified, most feature-complete, and most documented shader language. I'm writing a Vulkan engine on Windows and Linux, and I only use HLSL. Additionally Vulkan runs on macOS with MoltenVK (and now 'KosmicKrisp'), but I suppose the Zed spirit is 'platform-native and nothing else'. > symbolicating stack traces requires a .pdb file that is too large to ship to users as part of the installer. Perhaps publishing a symbol server[3] is a good idea here, rather than users shipping dump files which may contain personally-identifiable information; users can then use WinDbg or Visual Studio to debug the release-mode Zed at their leisure. [1]: https://github.com/zed-industries/zed/issues/35205 https://github.com/zed-industries/zed/issues/35205 [2]: https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8bd5dfe5d43972bc8de768ca6/crates/gpui/src/platform/windows/shaders.hlsl https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8b... [3]: https://randomascii.wordpress.com/2020/03/14/creating-a-public-symbol-server-easily/ https://randomascii.wordpress.com/2020/03/14/creating-a-publ...

andrewmcwatters 1y ago
Yeah, I maintain a Vulkan backend, and this immediately triggered my internal "what?" alarm. Modern Direct3D is almost indistinguishable from Vulkan, on the other hand. So it shouldn't be difficult for them to add. I also agree with your HLSL comment. It sounds like these guys don’t have much prior graphics or game development experience.
- delta_p_delta_x 1y ago
  I'd been thinking about it, and I added another paragraph above. I get a feeling they've been targeting Vulkan 1.3 with dynamic rendering from the beginning, so porting to D3D12 would be roughly as complex as rewriting to target older Vulkan.
maxbrunsfeld 1y ago
The Zed spirit is definitely to prefer a platform native solution. You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly. Good point that we should publish a symbol server.
- jamienicol 1y ago
  Did you consider using wgpu instead of writing a new dx11 renderer? It has metal, vulkan and dx12 backends so could have been used for a single renderer for macOS windows and Linux. (And webgpu in the future)
- bsder 1y ago
  > But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Except that everything has effectively converged to HLSL (via Slang which is effectively HLSL++) and SPIR-V (coming via Shader 7). So, your pipelines, shader language, and IR code would all look mostly the same between Windows and Linux if you threw in with DX12 (which looks much more like Vulkan) rather than DX11. And you'd get the ability to multi-thread through the GPU subsystem via DX12/Vulkan. And, to be fair, we've seen that MoltenVK gets you about 80-90% of native Metal performance on macOS, so you wouldn't have to maintain a Metal backend, anymore. And you'd gain the ability to use all the standard GPU debugging tools from Microsoft, nVidia, and AMD rather than just RenderDoc. You'd abandon this all for some mythical future compatibility with WebGPU--which has deployment counts you can measure with a thimble?

RattlesnakeJake 1y ago

Entirely unrelated, but the sections, toolbars, and controls in that RenderDoc app are so cleanly separated compared to modern dev tools. I wish more apps still looked like this.

jbverschoor 1y ago
I have my macOS set up that all buttons have borders etc If I switch no vanilla macOS, it’s basically unusable Clean, but unusable

mxhwll 1y ago

This is why you don’t make your own cross platform toolkit.

andsoitis 1y ago
while I would agree in general, there could theoretically be SOME applications where the range of UI controls (and systems) is small enough where it could pay off. But things tend to expand in surface area... So with that, this presents a HUGE opportunity for someone to build something akin to Zed, but not with the baggage that their technical strategy brings.
- cosmic_cheese 1y ago
  > So with that, this presents a HUGE opportunity for someone to build something akin to Zed, but not with the baggage that their technical strategy brings. Not sure it’s so clean-cut. More than avoiding baggage, you’re just shifting it elsewhere. The question is if you want to own (and can handle) the baggage and benefit from the control that brings.
WD-42 1y ago
You'd rather see another crappy, slow editor packaging an entire browser? Because that seems like what people are using for "cross platform toolkits" these days. I'm glad Zed is being ambitious, it's truly a joy to use because it feels native. And to be honest, it's Windows, who cares. If you are a developer you should have switched to Linux years ago anyway.
- steve_adams_86 1y ago
  No, there are good reasons developers are on Windows. Industrial and embedded systems are very often Windows-based, for better or worse. Heaps of games are developed on Windows. Windows-based software itself is developed on Windows.
  - com2kid 1y ago

Thaxll 1y ago

Why dx11 and not 12? No one should care about win7 in 2025.

Analemma_ 1y ago
Think about the customer base: the sorts of users who want a high-performance text editor are exactly the kind of people who will run Windows 7 until it's pried from their cold, dead fingers, and who will flood the support forums with complaints if you limit support to operating systems released in the last 15 years. Because of their target market, Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
- delta_p_delta_x 1y ago
  > Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter. This is incongruous given Zed uses modern frameworks (which is why they moved to D3D11 from Vulkan in the first place). If Zed really wanted to target 'old Windows' then they might have used Win32 and GDI+, not D3D11. In fact they could've stuck to D2D (which was released with Windows 7 and back-ported to Vista), and not used their own rendering at all, since D2D is already a GPU-accelerated text-rendering API, and then used Win32 windowing primitives for everything else.
- Someone 1y ago
  Similarly, the Mac version is for MacOS 10.15 (from 2019) or later, and has an x64 version.
  - zamadatix 1y ago
    Zed had already targeted macOS when 10.15 still had over a year of support left https://github.com/zed-industries/zed/commit/b400449a58507cca1fa007197929c2cfd6beabbe https://github.com/zed-industries/zed/commit/b400449a58507cc... and some variant of x86-64 macOS will still be supported through 2028. Neither of these were adding support for really old things, one is current for many years to come and just there hasn't been a reason to break 10.15 support yet so why bother. Meanwhile Windows 7 is already over 2 years past the end of extra-extended support at the time this new code was written with Windows 7 support still in mind. Which is nice, but a very different scenario.

guluarte 1y ago

[flagged]

CharlesW 1y ago
Add `—dangerously-skip-permissions` so you can sleep.

dang 1y ago

Related ongoing threads: Zedless: Zed fork focused on privacy and being local-first - https://news.ycombinator.com/item?id=44964916 https://news.ycombinator.com/item?id=44964916 Sequoia backs Zed - https://news.ycombinator.com/item?id=44961172 https://news.ycombinator.com/item?id=44961172

munchler 1y ago

I’m sure this is a dumb question, but why does a code editor need to render on the GPU like a video game? Is it just for niceties like smooth scrolling?

delta_p_delta_x 1y ago
> but why does a code editor need to render on the GPU like a video game? It isn't just text editors—nowadays, everything renders on your GPU, even your desktop and terminal (unless you're on a tty). For example, at the bottom of Chromium, Electron, and Avalonia's graphics stack is Skia, which is a cross-platform GPU-accelerated windowing and 2D graphics library. GPU compositing is what allows transparency, glass effects, shadowing, and it makes actually writing these programs much easier, as everything is the same interface and uses the same rendering pipeline as everything else. A window in front of another, or a window partially outside the display? No big deal, just set the 3D coordinates, width, and height correctly for each window, and the GPU will do hidden-surface removal and viewing frustum clipping automatically and for free, no need for any sorting. Want a 'preview' of the live contents of each window in a task bar or during Alt-Tab, like on Windows 7? No problem, render each window to a texture and sample it in the taskbar panels' smaller viewports. Want to scale or otherwise squeeze/manipulate the contents of each window during minimise/maximise, like macOS does? Easy, write a shader. This was a big deal in the early 2000s when GPUs finally had enough raw compute to always run everything, and basically every single OS and compositor switched to GPU rendering roughly in the same timeline—Quartz Extreme on Mac OS X, DWM.exe on Windows, and Linux's variety of compositors, including KWin, Compiz, and more. There's a reason OSs from that time frame had so many glassy, funky effects—this was primarily to show off just how advanced their GPU-powered compositors were, and this was also a big reason why Windows Vista fell so hard on its face—its compositor was especially hard on the scrawny integrated GPUs of the time, enough that two themes—Aero Basic, and Aero Glass—had to be released for different GPUs.
- munchler 1y ago
  Thanks. That explains why OSs use the GPU for rendering windows and effects, but it's still not clear to me why a code editor would do the same. The features you list (transparency, glass effects, shadowing, window management, etc.) seem to be outside the purview of a text editor. If you're saying that Zed is built on something like Skia, then it would already be cross-platform and not have to worry about Vulkan vs. DirectX, right?

spapas82 1y ago

For people that use scoop and want to try Zed there's a precompiled binary they can install using scoop install zed. I tried it and the experience (mainly visually, fonts colours etc) wasn't very good so I can understand why the Zed developers are reluctant to formally release windows binaries.