41–50 of 83 posts
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.
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, releas…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
Not selling you on it, as I find that, if you're using IDEs, OSes don't really matter. And windows can be actually beneficial as you'll get prime support from most vendors. Where Unix shine is adhoc automation. Almost everything is fully hackable and that makes some solution easier to implement. As in case for the desktop, you can switch out your audio stack, alter the display of any element and many other things. Us…
Do you have any easy automations in mind that would be broadly appealing and one really needs to go out of their way to implement on Windows / is impossible to do so? I have a few things here and there, but it's more a scheduled script or two than anything more elaborate, and I don't think they were difficult to make and deploy. > you can switch out your audio stack Why would I want that? Isn't this more for someone…
There’s no broad stroke here. It’s more about the possibility to adjust something here and there. I don’t have anything against windows technically (I’ll use it with no complaints if it’s work provided).
When I notice something I don’t like (workflow mostly instead of appearance), I want to be able to fix it instead of suffering it (unless I’m being paid).
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?
> 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 eff…
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?
This is why you don’t make your own cross platform toolkit.
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.
These days, WSL2 effectively eliminates a need for that for most developers.
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, releas…
Not everywhere. See the middle bug report, "Zed does not work in Remote Desktop session on windows" (https://github.com/zed-industries/zed/issues/26692).
Most Remote Desktop/Terminal Services environments won't have any Vulkan devices available, unless you ship your own software rendererer (like SwiftShader).
Also, NVIDIA only supports Vulkan on Kepler (GTX 600 series), AMD on GCN 1.0 (Radeon HD 7000 series), and most importantly, Intel on Skylake (6000 series). Especially on the Intel side, there are plenty of old but still-supported Windows 10 machines that lack Vulkan support. For many applications that's ok, but IMO not for a text editor.
Earlier quoted context omitted.
> 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 eff…
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.…
Happy to elaborate further.
Old school text rendering began with a table of character codes to actual, fixed-size bitmaps (this was a font), and rendering was straightforward: divide the framebuffer resolution by the bitmap resolution, clip/wrap the remaining, just place the bitmaps into the resultant grid, and pipe the framebuffer to the display. Done.
Nowadays, text editors don't just have text; they have markup like highlighting and syntax colouring (with 24-bit deep-colour, rather than the ANSI 16 colour codes), go-to, version control annotations, debug breakpoints, hover annotations, and in the case of 'notebooks' like Python notebooks, may have embedded media like images, videos, and even 3D renders. Many editor features may open pop-up windows or dialogue boxes, which will probably occlude the text 'behind'.
Now, most modern text editors also expect to work with non-bitmapped, non-monospaced typefaces in OpenType or TrueType format. These are complex beasts of their own with hinting, ligatures, variable weights, and more, and may even embed entire programs. They are usually Bezier/polynomial splines that the GPU can rasterise easily in hardware (no special shader required). After this rasterisation, any reasonable text editor will apply anti-aliasing, which is also work delegated to the GPU. There is probably a different algorithm for text (which needs to account for display subpixel layouts) versus UI elements (which may not).
The point I am driving at is that the proliferation of features expected from a modern text editor means that using a GPU for all of this is a natural evolution. As users, we may think 'it's just text' but from the perspective of the developer or the hardware, text and a ray-traced 3D game is no different: it's one 4D square matrix multiplied by another, one after another, and in the end reduced into a three-vector, representing the colour of a pixel.
> 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?
Absolutely, because Skia handles that for the developer. And I suspect the reason why Zed didn't use Skia in the first place is ideological (Skia is by Google, written in C++), together with wanting to write 'the whole world' in Rust.
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, releas…
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 th…
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?
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, releas…
I suspect because a huge amount of software engineers develop on Macbooks and consider Linux second and Windows third. Culturally, I think there's a difference in tooling between Graphics developers (who would go straight for HLSL, cross-platform Vulkan, or even SDL3) and mac users (who reach for Apple tools first)