Thoughts in Winnit and WGPU?

[Quick-Flash]

Moving away from what gpui does and just using winnit and WGPU sounds much more maintainable than what zed is doing.

[coolbluewater]

Out of curiosity, what is zed doing? I noticed this repo has no dependency on winit/wgpu and wondered why, which led me here.

[Vanuan]

@coolbluewater zed depends on wgpu on Linux, but uses metal/winapi on respective platforms.
On Linux it uses direct Wayland/X11 calls instead of winit.

[Augani]

Thanks for raising this. Kael does not currently depend directly on winit or wgpu.
Kael uses one retained application and view model, but the platform layer is specialized:

• macOS uses native windowing and Metal.
• Windows uses Win32 and Direct3D 11.
• Linux uses Wayland or X11 with Blade/Vulkan, plus a GTK4/GSK host when native WebView composition is needed.
• The browser uses canvas and WebGL2.

winit and wgpu are both strong projects, and using them could reduce some platform-specific code. The tradeoff is that Kael needs close control over window lifecycle, display scaling, IME, accessibility, drag and drop, WebView composition, frame scheduling, damage tracking, GPU memory, and device recovery. Those details matter for the document suites, editors, creative tools, and game-like workloads Kael targets.

I am not opposed to using either project where it provides a clear improvement. Kael’s platform and renderer traits allow me to evaluate that without changing the public application API. Any adoption would need to match the existing macOS, Windows, Linux, and browser runtime proofs, including performance, DPI and font consistency, WebView integration, artifact size, and device-loss handling.
So the direction is not “never winit or wgpu.” It is to keep the public framework portable while selecting the backend that gives Kael the strongest integration and performance on each platform since i use it myself in building my own applications.