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

91–100 of 212 posts

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

#91

Post by avereveard »

TiredOfLife wrote: post #81
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.

For one that's not entirely true. standard windows gui calls are backed by a shared surface and accumulate drawing instruction on the system side of the render surface,managed by the cpu render pipeline, so that they can keep a dirty rectangle list and only update the dirty areas of the gpu side of the shared surface. From there composing runs on the gpu.

Then again the issue is the focus of rendering at 120fps.the rendering context should be paused between the vast nothingness that happens in between user keystrokes, that happen at something like 4kp, and in burst.

The insistence on 120fps is the issue here, not the rendering pipeline.

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

#92

Post by gabereiser »

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…

The absolutism of some of their statements when we have 30 years of GPU research at our disposal is pretty eye-opening. I get that maybe this stuff didn't exist as a crate for rust but c'mon! Splines and shapes, glyph rendering, I wrote a game engine in C# back in 2007 that did all these things, and more. I like the explanation and the breakdown of SDFs for primitives but they are standing on the shoulders of giants and act like they're on an island.

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

#93

Post by flohofwoe »

It's surprising that they jump immediately from the problem description into shader details.

IME the main theme with achieving high performance not just in games, and not just in rendering, is to avoid frequent 'context switches' and instead queue/batch a lot of work (e.g. all rendering commands for one frame) and then submit all this work at once "to the other side" in a single call. This is not just how modern 3D APIs work, but is the same basic idea in 'miracle APIs' like io_uring

This takes care of the 'throughput problem', but it can easily lead to a 'latency problem' (if the work to be done needs to travel through several such queues which are 'pipelined' together).

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

#94

Post by decremental »

littlestymaar wrote: post #89
pama wrote: post #52

Earlier quoted context omitted.

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.

I use egui. The library itself is agnostic but relies on backend libraries for rendering, all of which (or at least the official ones) render on the GPU.

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

#95

Post by fallat »

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'm not even sure it was wise to use SDFs to draw some shaded rounded rectangles.

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

#97

Post by gizmo »

fxtentacle wrote: post #85
ben-schaaf wrote: post #47

Earlier quoted context omitted.

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.

That's not sufficient, though. You want the 0.1% case where you press undo a couple of times and big edit operations get reversed to be smooth. You have to hit your frame target when a lot is happening, the individual key press case is easy.

It's just like a video game. A consistent 60fps is much better than an average frame rate of 120fps that drops to 15fps when the shooting starts and things get blown up. You spend all the time optimizing for the worst case where all your caches get invalidated at the same time.

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

#98

Post by scotty79 »

dorkwood wrote: post #10
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…

> KiCad uses a technique using RGB for gradients so that the rendered glyphs can be anti-aliased without accidentally rounding sharp corners. This is known as a “multi-channel signed distance field”, or “msdf”. https://github.com/Chlumsky/msdfgen

Do you know any text editor that uses it for font rendering?

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

#99

Post by flohofwoe »

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 mainly used for debug rendering, but if you browse the screenshot threads, there quite a few 'end user applications' among them:

https://github.com/ocornut/imgui/issues/5886

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

#100

Post by flohofwoe »

pjmlp wrote: post #66
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.

Accessiblity, designer,... and it isn't even the first, that is how GUIs used to be developed in 16 bit home computers for games. It is like static linking, it was also there decades ago. There are reasons why the world has moved on from those approaches.

What's your point? Static linking makes a ton more sense than dynamic linking, except in a few special case niches (like plugin systems).

And OTH, event-driven UIs have also been around as long as UIs exist, that makes them at least as 'outdated' as immediate mode UIs.

Post reply on HN