| ▲ | ZeroCool2u 3 hours ago |
| An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server. |
|
| ▲ | nu11ptr 3 hours ago | parent | next [-] |
| 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 29 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. |
|
|
| ▲ | nindalf 3 hours ago | parent | prev | next [-] |
| Quoting maddythewisp from that PR: > There is significant work beyond the renderer that would need to happen to run Zed in a browser - notably background tasks and filesystem/input APIs would need web/wasm-compatible implementations. |
|
| ▲ | rafaelmn 3 hours ago | parent | prev | next [-] |
| Rendering in the browser has nothing to do with being able to do remote editing like you can in VSCode - you would just be able to edit files accessible to the browser. Just like you can hook up local VS code native up to a random server via SSH, browser rendering is just a convenience for client distribution. You would need a full client/server editor architecture that VS code has. |
| |
|
| ▲ | arghwhat 3 hours ago | parent | prev | next [-] |
| Well, not really. It means you have a renderer that is closer to being portable to web, not an editor that will run in web "with some additional work". The renderer was already modular before this PR. |
|
| ▲ | usefulcat 2 hours ago | parent | prev | next [-] |
| If you're talking about remote editing (editing files which reside on a remote server), Zed already supports that? |
| |
| ▲ | Octoth0rpe 2 hours ago | parent [-] | | I believe they're referring to running Zed entirely in a browser. This opens up possibilities like using zed for something like codepen, or embedding it into a git web frontend like gitea. Many projects like this basically embed vscode, a rare benefit of being an electron app which Zed is not. | | |
|
|
| ▲ | readitalready 3 hours ago | parent | prev [-] |
| Can this be done on a cheap AWS EC2 instance? |
| |
| ▲ | ZeroCool2u 3 hours ago | parent [-] | | Sure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted. |
|
