A bit of a tangent, but I wish the makepad project would get more traction in rust. Their cross-platform approach is extremely ambitious.
Zed editor switching graphics lib from blade to wgpu
31–40 of 321 posts
Re: Zed editor switching graphics lib from blade to wgpu
#32Seeing that the author of Blade (kvark) isn't exactly a 3D API newbie and also worked on WebGPU I really wonder if a switch to wgpu will actually have the desired long term effect. A WebGPU implementation isn't exactly slim either, especially when all is needed is just a very small 3D API wrapper specialized for text rendering.
Re: Zed editor switching graphics lib from blade to wgpu
#33Earlier quoted context omitted.
Interesting read, however as someone from the same age group as Casey Muratori, this does not make much sense. > The "immediate mode" GUI was conceived by Casey Muratori in a talk over 20 years ago. Maybe he might have made it known to people not old enough to have lived through the old days, however this is how we used to program GUIs in 8 and 16 bit home computers, and has always been a thing in game consoles.
I mean, fair enough, but [at least] wikipedia agrees with that take. > Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a butto…
Dig out any source code for Atari, Spectrum or Commodore 64 games, written in Assembly, or early PC games, for example.
And you will see which information is more accurate.
Re: Zed editor switching graphics lib from blade to wgpu
#34Earlier quoted context omitted.
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.
> 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.
Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.
Re: Zed editor switching graphics lib from blade to wgpu
#35An 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.
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.
[deleted]
Re: Zed editor switching graphics lib from blade to wgpu
#36Earlier quoted context omitted.
I mean, fair enough, but [at least] wikipedia agrees with that take. > Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a butto…
Dig out any source code for Atari, Spectrum or Commodore 64 games, written in Assembly, or early PC games, for example. And you will see which information is more accurate.
Yeah no doubt you're correct. I wasn't disagreeing - just establishing the reasonableness of my original statement. I must have read it in the Dear ImGui docs somewhere.
Re: Zed editor switching graphics lib from blade to wgpu
#37Earlier quoted context omitted.
Really? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.
The problem is that Zed has understandably and transparently abandoned supporting GPUI as an open source endeavour except to the extent contributions align with its business mission.
I remember when that came out, but I'm not sure I understand the concern. They use GPUI, so therefore they MUST keep it working and supportable, even if updating it isn't their current priority. Or are you saying they have a closed source fork now?
Actually, this story is literally them changing their renderer on linux, so they are maintaining it.
> except to the extent contributions align with its business mission
Isn't that every single open source project that is tied to a commercial entity?
Re: Zed editor switching graphics lib from blade to wgpu
#38Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop
Really? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.
I tried gpui recently and I found it to be very, very immature. Turns out even things like input components aren't in gpui, so if you want to display a dialog box with some text fields, you have to write it from scratch, including cursor, selection, clipboard etc. — Zed has all of that, but it's in their own internal crates.
Do you know how well gpui-component supports typical use cases like that? Edit boxes, buttons, scroll views, tables, checkbox/radio buttons, context menus, consistent native selection and clipboard support, etc. are table stakes for desktop apps.
Re: Zed editor switching graphics lib from blade to wgpu
#39Earlier quoted context omitted.
> 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.
Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.
[deleted]
Re: Zed editor switching graphics lib from blade to wgpu
#40Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop
Can I humbly ask how are LLMs and Rust GUIs related?