From the PR, it sounds like the switch to WGPU is only for linux. The team was reluctant to do the same for macOS/Windows since they felt their native renderer on those platforms was better and less memory intensive.

▲

swiftcoder 3 hours ago | parent | next [-]

> they felt their native renderer on those platforms was better and less memory intensive

This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.

▲

nicoburns 25 minutes ago | parent | next [-]

> This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.

They probably will for memory usage. Current wgpu seems to have a floor around ~100mb that isn't there with other rendering backends (and it was more like ~60mb with wgpu a few months / versions ago).

Not sure if this is fixable in wgpu, or do with spec compatibility (my guess would be that it's fixable, just not top priority for the team atm).

▲

MindSpunk 2 hours ago | parent | prev | next [-]

WGPU is just a layer over the top of the native APIs on any given platform so unless Zed's DirectX/Metal renderers were particularly bad it's unlikely WGPU will be better here.

	▲	swiftcoder an hour ago \| parent [-]
		I'm not saying it would be better, I'm saying it may not be particularly much worse. Which still might make it worth simplifying everything by settling on one rendering abstraction

▲

flohofwoe 3 hours ago | parent | prev | next [-]

WebGPU has some surprising performance problems (although I only checked Google's Dawn library, not Rust's wgpu), and the amount of code that's pulled into the project is massive. A well-made Metal renderer which only implements the needed features will easily be 100x smaller (in terms of linecount) and most likely faster.

	▲	pjmlp 2 hours ago \| parent [-]
		There is also the issue that it is designed with JavaScript and browser sandbox in mind, thus the wrong abstraction level for native graphics middleware. I am still curious how much uptake WebGPU will end up having on Android, or if Java/Kotlin folks will keep targeting OpenGL ES.

▲

2 hours ago | parent | prev | next [-]

[deleted]

▲

vitorsr 2 hours ago | parent | prev [-]

Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.

	▲	swiftcoder an hour ago \| parent \| next [-]
		I don't think it would, but I don't think it's a given that their homegrown renderer is wildly more performant either - people tend to overestimate the performance of naive renderers
	▲	2 hours ago \| parent \| prev [-]
		[deleted]

▲

ZeroCool2u 3 hours ago | parent | prev [-]

Yes, but they can add a flag to switch renderers on startup like they had for blade.