Porting blade to Windows

[JunkuiZhang]

I have ported the blade renderer from Linux to Windows using the cross-platform winit library. I would like to contribute a PR, but there are currently many issues that need to be discussed with zed.

1. Currently, many tree-sitter plugins cannot be compiled on Windows, such as tree-sitter-gitcommit. Can the treesitter-related crates be moved from workspace to zed/Cargo.toml? This way, [target.'cfg(not(target_os = "windows"))'.dependencies] can be used to avoid compiling on Windows.

2. The currently used async-tar cannot be compiled on Windows, and the source repository has not been updated for 3 years. I have forked the source repository and made some modifications. Can zed fork the original repository so that we can use zed-industry's async-tar instead of my personal one?

3. The winit library supports Linux, Windows, and web. It currently works well on Linux. Do we need to merge Linux and Windows? Since Linux and Windows impl have very little difference. I have made a simple merge in my library (but I have not deleted the original code), but I am not sure if this is the best approach, or we just keep it as is?

Zed running on Windows

Zed running on WSL(Ubuntu) using winit

My repo

I would appreciate your feedback on these issues.

[SomeoneToIgnore]

cc @mikayla-maki and @kvark as people with the most context

[kazatsuyu]

Some tree-sitter modules have been modified in upstream. This is my PR, but it is still in Draft because one fix is not complete. Other than that, I think you can avoid the error by putting in the same update.

[JunkuiZhang]

I will start providing PRs after your PR is merged. Thank you for your work! BTW, 龙年大吉！

[kazatsuyu]

龙年大吉！ I am Japanese, so I celebrated the New Year a month ago, but it is still the Year of the Dragon, lol

[kvark]

This is great, thank you for sharing @JunkuiZhang !
We have a few other contirbutors also actively looking at Windows support and getting it to work with varying levels of completeness.

I have ported the blade renderer from Linux to Windows using the cross-platform winit library

Last time we discussed winit in Zed on Discord, there was a tentative agreement to try implementing the windowing logic ourselves.
I can't speak for Zed team, but generally I don't think we want to be in a situation where some platforms use custom windowing backends while others use winit. If Zed team wants to try out winit, I imagine they'd want to use it everywhere.
Thus, I'm (personally) curious how bad the windowing code would be in Windows port of Zed if it was written directly using winapi. It's a good opportunity to go all in with https://github.com/microsoft/windows-rs, which is fairly recent.

Edit: oh, and also just today we got "#windows-port" channel on Discord. Please join to chat!

[JunkuiZhang]

Thank you very much for your response! I also lean towards using the windows crate for implementing on the Windows platform as it offers a lot more flexibility compared to winit (mainly due to the limitations of winit's EventLoop). Winit makes it easy to port Zed to the web, which is why I asked Zed team's opinion. Additionally, is the decision to use Blade for the renderer on Windows final, or is it just a temporary solution with plans to transition to D3D12 in the future?

[kvark]

I'm not aware of discussions about having a D3D12 backend. If there is such need, I'd expect it to be somewhere very low on the priority list, since the set of hardware supporting D3D12 is very close to Vulkan, and we already have Vulkan via Blade.

One possible developments in the future would be to add D3D12 backend to Blade itself, but so far I haven't seen good motivation for it.

What is more important than D3D12, I think, is accessing the platforms that can't run Vulkan (or D3D12). There is a path to this via Blade - it can build with GLES-3.1 backend and run with Angle DLL bundled in. This will translate it to D3D11, which is available on all Windows.