Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leveraging Rust and the GPU to render user interfaces at 120 FPS

zed.dev

Post reply on HN
Print view View original

41–50 of 212 posts

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#41

Post by marginalia_nu »

shultays wrote: post #26
fxtentacle wrote: post #2

"Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework" I'm surprised you did not look at "Dear ImGui", "Noesis", and "JUCE". All three of them are heavily used in gaming, are rather clean C++, use full GPU acceleration, and have visual editors available. Especially JUCE is used for A LOT of hard-realtime professional audio applications. "Wh…

ImGui is at least only used for debug rendering, not something that makes it to end user. At least in the small subset of companies I worked at.

ImGui is amazing to work with though. Like holy fuck is it pleasant compared to basically every other UI-development paradigm ever in the history of user interfaces.

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#42

Post by as-cii »

xlii wrote: post #33

That's exactly the rabbit hole I'm in. I love immediate feedback but getting it ranges from hard to neigh impossible. E.g. I have a complex Emacs setup for rendering Pikchr diagrams, but there are a lot of problems to solve from diagram conception to the end result, so I thought, hey, why not make my own cool RT editor - in Rust obviously. Unfortunately I learned that GUIs are though problem especially if idea is hob…

Hey xlii! This is Antonio, author of the post.

You're right that rendering is only part of the story. To stay within the ~8ms frame budget, however, every little bit counts. Maintaining application state, layout, painting, and finally pushing pixels to screen, all need to be as performant as they can be.

For layout specifically we're using an approach inspired by Flutter, which lets us avoid complex algorithms but still have a lot of flexibility in the way elements can be positioned and produce a rich graphical experience.

Thanks for reading and commenting!

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#44

Post by coldtea »

swatcoder wrote: post #7
fxtentacle wrote: post #2

"Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework" I'm surprised you did not look at "Dear ImGui", "Noesis", and "JUCE". All three of them are heavily used in gaming, are rather clean C++, use full GPU acceleration, and have visual editors available. Especially JUCE is used for A LOT of hard-realtime professional audio applications. "Wh…

I agree with your final statement and the seeming lack of research, but are you sure your characterization of JUCE is accurate? You’d surprise a lot of people if you were right about it using GPU acceleration for its UI framework. It does have an OpenGL container that fits into its view object hierarchy if you want to write your own accelerated component, but the rest of the UI is pretty much standard event-loop -> p…

>I agree with your final statement and the seeming lack of research, but are you sure your characterization of JUCE is accurate?

That JUCE is "heavily used in gaming" for starters is widly innacurate

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#45

Post by xlii »

as-cii wrote: post #42
xlii wrote: post #33

That's exactly the rabbit hole I'm in. I love immediate feedback but getting it ranges from hard to neigh impossible. E.g. I have a complex Emacs setup for rendering Pikchr diagrams, but there are a lot of problems to solve from diagram conception to the end result, so I thought, hey, why not make my own cool RT editor - in Rust obviously. Unfortunately I learned that GUIs are though problem especially if idea is hob…

Hey xlii! This is Antonio, author of the post. You're right that rendering is only part of the story. To stay within the ~8ms frame budget, however, every little bit counts. Maintaining application state, layout, painting, and finally pushing pixels to screen, all need to be as performant as they can be. For layout specifically we're using an approach inspired by Flutter, which lets us avoid complex algorithms but st…

I don't have experience with Flutter, but based on quick glance they're using widgeting and, what I found quite important - ability to develop GUI outside of the application. Something that I think libraries like egui are missing (and which is easily obtainable with Tauri/Dioxus).

Rebuilding whole app to ensure that some box doesn't get cut off ruins development experience, especially for big apps.

Kudos to you guys, I hope you'll make Zed extensible, so that instead of writing my own editor I can use yours ;-)

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#46

Post by Hikikomori »

DeathArrow wrote: post #22

According to Wiki, the technique was invented in 2005 by Casey Muratori: https://en.wikipedia.org/wiki/Immediate_mode_GUI

Casey ranting about how slow visual studio is and compares it to RemedyBG that uses Dear Imgui (an implementation of Immediate mode GUI).

https://www.youtube.com/watch?v=GC-0tCy4P1U

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#47

Post by ben-schaaf »

yason wrote: post #17

The bottleneck of UI is not the rendering. A measly 60 fps is plenty fast for UI that feels immediate. We had this in the 90's with software rendering, you don't need a GPU for that today. What causes user interfaces to hick up is that it's too easy to do stuff in the main UI thread. First it doesn't matter but stuff does accumulate, and eventually the UI begins to freeze briefly for example, after you press a button…

Unfortunately this isn't true anymore when you get to very high resolutions like 8k. Just clearing the framebuffer of an 8k display at 60hz requires ~6GB/s; about 1/10th of the theoretical memory bandwidth of modern desktop processors. Add in compositing for multiple windows, text rendering and none of that likely being multi-threaded it's pretty clear a CPU has no chance of keeping up.

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#48

Post by samsaga2 »

DeathArrow wrote: post #20

What's wrong with using platform APIs? I think that by 2023 most UI toolkits provided by the OS are hardware accelerated.

Smooth animations and performance. Draw a big image with Win32 BitBlt it's painful slow, for example. Imagine that you are zooming an image in Photoshop and it is laggy, the user experience would be horrible. Also, the lag is an important issue in the user interface, even something so small like 100ms would be bad.

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#49

Post by pflanze »

Gigachad wrote: post #14
bruce343434 wrote: post #13

Earlier quoted context omitted.

If you want to do this, where can you start? What are some patterns for making code that's not too spaghetti when you have to handle tabbing, focus, layout, speech of element contents, the actual hierarchy of the elements etc? Are there standardized OS accessibility API hooks or something?

I’ve heard it’s hard to even work this out as all of the screen reader tools are expensive, proprietary, and there are no standards. The typical way is to just make your program, and if it gets popular, the screen reader companies will find a way to make their product work.

Here are recent suggestions for Windows and Linux by a blind person: https://news.ycombinator.com/item?id=35008647

Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS

#50

Post by as-cii »

almostdigital wrote: post #40

Looking forward to trying this, VSCode is great but I really miss the performance of Sublime Text. I hope they get the plugin system right, killer feature would be if it could load VSCode plugins (incredibly hard to pull off, yes)

Thanks, almostdigital!

After our past experience with Atom, getting the plugin system right is a top priority for the editor.

The thought of cross compatibility with VSCode plugins definitely crossed our mind and it's not out of the question, although our current plan is to initially support plugins using WASM.

Post reply on HN