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

81–90 of 212 posts

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

#81

Post by TiredOfLife »

avereveard wrote: post #67

I cannot stress how much I do not want my 300w gpu to be used to render text that change at most three times per second. And it's not just about electricity cost and heat stress, it will conflict with everything else that requires the gpu to do stuff, including watching 4k videos on the second monitor, which does have a legitimate case for requiring hardware acceleration since they move a lot of data 60 times per sec…

Unless you use Templeos your OS is already using gpu to do gui rendering and composing.

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

#82

Post by legosexmagic »

jspdown wrote: post #62
marginalia_nu wrote: post #41

Earlier quoted context omitted.

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.

Yes but that's because it's an immediate mode renderer. It feels intuitive and that's why it's the de facto standard for building debug tooling. But this intuitiveness comes at a price! No matter how hard you try, this will always be slower and computationally heavy compared to retained mode. Great for some stuff, terrible choice for some other.

Your mixing up terms.

immediate mode rendering and immediate mode gui are unrelated. immediate mode gui libraries generally dont use immediate mode rendering because its realy slow.

immediate mode gui tends to be faster in practice because you just naturally end up with less code. also its very easy to write a retained mode ui ontop of an immediate mode gui library.

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

#83

Post by fxtentacle »

littlestymaar wrote: post #9
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…

> What are you talking about? JUCE has had GPU-accelerated spline shapes and SVG animations since 2012? I'm not familiar at all with JUCE, but the state of the art in GPU-accelerated 2D graphics has dramatically improved over the past 10 years so I doubt what JUCE did in 2012 is really comparable.

I shipped a JUCE-based app in 2012 and back then it was "good enough" to have GPU-accelerated rendering of SVG icons moving around in realtime with antialiasing. Since we used their OpenGL context, we could even render the GUI inside customers' games for debug visualization.

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

#84

Post by acdha »

rafram wrote: post #80

[flagged]

Why are you reacting so emotionally to something that far down the page? They’re talking about being aggressively multi-core and given their technical audience it hardly seems inappropriate to have that detail along with the other details like how they use GPU acceleration and the benefits of lower input latency.

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

#85

Post by fxtentacle »

ben-schaaf wrote: post #47
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.

You are correct, but so is the comment you replied to.

The latency that matters for a text editor is how long it takes for a new keypress to show up. And that's usually a 32x32 pixel area or less.

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

#87

Post by rafram »

acdha wrote: post #84
rafram wrote: post #80

[flagged]

Why are you reacting so emotionally to something that far down the page? They’re talking about being aggressively multi-core and given their technical audience it hardly seems inappropriate to have that detail along with the other details like how they use GPU acceleration and the benefits of lower input latency.

I wouldn’t say I’m reacting emotionally, or that where it is on the page is relevant. It’s just a funny part of their marketing copy.

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

#89

Post by littlestymaar »

pama wrote: post #52
littlestymaar wrote: post #27

Earlier quoted context omitted.

Afaik egui isn't doing any kind of the fancy GPU based 2D graphics this blog post is about though.

It uses glow, GL on whatever, so OpenGL when it exists.

That doesn't mean it's doing any kind of GPU acceleration of 2D graphics.

Given that they don't talk about it in the README, I'm pretty sure they don't.

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

#90

Post by mike_hearn »

zodester wrote: post #64
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…

React Native follows this pattern by moving most JS processing off the main thread allowing scrolling and other input to happen without blocking for a response from the JS VM. However this does end up causing a lot of problems with text input and gestures as now you have a sync issue between the threads, if you get caught processing a bunch of stuff in the JS thread the app may appear to be responsive with scrolling…

Yes, making GUIs responsive isn't as simple as just "don't run stuff on the UI thread". There are good reasons to run stuff there even if you're going to hang up the app for a brief period, namely, the user won't see partial/incorrect updates like non-syntax highlighted text or incorrectly clipped shapes, and - especially important - it means you can't end up with invalid GUI states like the user pressing a button that does X and then immediately pressing another button that does the opposite of X, where you should have disabled the other button but didn't get to it in time. Web apps have this sort of problem if they aren't using enough JS, and it can cause all kinds of weird bugs and errors.

The reality is that moving things off the UI thread is always a calculated engineering decision. It can be worth it, but it complicates the code and should only be done if there's a realistic chance of the user noticing.

Post reply on HN