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

31–40 of 212 posts

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

#31

Post by kaba0 »

DeathArrow wrote: post #21
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…

I think the bottleneck comes from updating each UI element instead updating them in batches and updating elements that don't need to be updated.

That’s just retained mode GUIs calculating what got damaged and only updating those. That’s how most GUI frameworks work since many decades.

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

#32

Post by nicoburns »

maeln wrote: post #11

While I do enjoy a nice and smooth gpu-accelerated ui, I never use a gpu-ui framework for my own project for one simple reason: Almost none of them properly support accessibility. Electron (and in general the web), despite its sluggishness has a very good support for accessibility. Most "traditional" native ui toolkit also do. That would be my advice to anyone making a gpu-accelerated ui library in 2023: Try to suppo…

I can’t speak for this one as it’s proprietary, but You’ll be pleased to hear that pretty much all the open source Rust GUI toolkits either integrate AccessKit or have concrete plans to do so in the immediate future. There are toolkits that can’t even do basic things like render images but have accessibility support :)

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

#33

Post by xlii »

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 hobby-based so there's only one developer inside. Ultra responsive GUIs cool, I have a prototype in egui (not sure if that's as fast as Zed's premise but feels fast nonetheless) and yet it doesn't support multiple windows, which I wanted to have.

120 FPS with direct rendering sounds AWESOME just for sake of it, but I believe that for the end-user layout will be more important than refresh rate, and that's different beast to tame.

Personally I "almost" settled for Dioxus (shameless plug: [1], there's link to YT video) and I'm quite happy with it. Having editor in WebView feels really quirky though (e.g. no textareas, I'm intercepting key events and rendering in div glyph-by-glyph directly).

[1]: https://github.com/exlee/dioxus-editor

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

#35

Post by sieabahlpark »

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…

[dead]

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

#36

Post by eptcyka »

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…

It's significantly cheaper to render a fullscreen window on the GPU than it is on the CPU if you're running at 2560x1600 or 4K. To push that many pixels, you have to send significant amounts of data (framebuffers) at 60 FPS to the GPU anyway - which is no small feat and is bound to eat into the battery. It's just more efficient to run on the GPU.

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

#37

Post by mariusmg »

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.

If their plan is to make their app crossplatform (Windows,OSX,Linux) and be very versatile with the UI customization , then maybe writing a small/focused specifically for your needs UI crossplatform toolkit is not such a bad idea (after all this is what Sublime Text is doing as well)

But the HW accelerated brag is pointeless. Even if they manage to squeeze some extra performance over native toolkits, that is not necessarely going to matter in the grand scheme of things. Drawing the UI is never the bottlneck in a text editor...

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

#38

Post by seanalltogether »

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…

Separating the logic thread from the render thread doesn't end up being the silver bullet to performance. If I press the letter 'a' on my keyboard and my IDE suddenly stalls on a bunch of code hinting logic, that new state is still not going to make it to the render thread for a couple frames. As long as the render thread is dependent on state coming in from the logic thread, the stalls still propogate.

You could have some wins around scrolling and any animations that you can commit ahead of time

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

#39

Post by andersa »

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.

I wonder if this is because the default theme for it is somewhat ugly, and most developers aren't designers to make it look better. It is perfectly capable of rendering standalone applications, if you want it to...
Post reply on HN