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

71–80 of 212 posts

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

#71

Post by pjmlp »

tcfhgj wrote: post #61
samsaga2 wrote: post #48

Earlier quoted context omitted.

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.

What about the winrt api?

Nee, Direct2D. Save yourself some pain.

WinRT has gone through multiple reboots, who knows what will happen still.

Better use the existing Win32/COM stuff.

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

#72

Post by alexfromapex »

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…

This UI is so lightweight it seems like they should easily be able to toggle the GPU compute on or off

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

#73

Post by tcldr »

tgflynn wrote: post #65

What API are they using for interfacing with the GPU (ie. OpenGL, Vulkan, other ) ? I suspect a lot of time is likely to be spent on the CPU side updating vertex and other data and pushing it to the GPU so it would be useful to have some more detail on how they are handling that.

I saw a few Metal specific types in the source code contained within their demo video

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

#74

Post by ohgodplsno »

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…

I have horrible news to tell you about compositors: they already do use your GPU, even if you're watching a 4K video on the side. Even when requesting a full screen swapchain to avoid having to deal with the compositor, modern OSes will force you to go through that compositor and lie about it being fullscreen.

Additionally, using your GPU doesn't mean locking your GPU on that task. Your 4K video most likely isn't taking up 100% of GPU time, nor 100% of the nearby onboard memory. Everyone already gets a share of that time.

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

#75

Post by ohgodplsno »

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…

As for text rendering, Slug [0] has existed for much more than ten years, and is pretty much the gold standard for GPU text rendering.

[0] https://sluglibrary.com/

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

#76

Post by smoldesu »

jug wrote: post #59

Wow, that’s some low level stuff. Most would just use an established UI framework because rendering performance is left to the window manager. I’m not sure I understand the need to go about it like this? Windows is not considered the epitome of performant interfaces but it has no trouble rendering UI’s at 120 fps. When people go and buy a 120 fps display, they are wowed by the smooth scrolling in a heavy application…

It's so weird. The devs of the Warp based terminal are doing something similar (Rust for single-platform low-level dev), and I'm also not sure what the point is. It feels like they're banking on Rust being a selling point, but forgot that the lang can drastically lower your iteration speed when it comes time to compete with other editors.

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

#77

Post by fxtentacle »

coldtea wrote: post #44
swatcoder wrote: post #7

Earlier quoted context omitted.

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

I personally know multiple people using it in their games and game-related tooling and Roli (the company selling JUCE) even has an official Unreal Engine 4 plugin. So to me, it appears to be widely used.

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

#78

Post by avereveard »

ohgodplsno wrote: post #74
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…

I have horrible news to tell you about compositors: they already do use your GPU, even if you're watching a 4K video on the side. Even when requesting a full screen swapchain to avoid having to deal with the compositor, modern OSes will force you to go through that compositor and lie about it being fullscreen. Additionally, using your GPU doesn't mean locking your GPU on that task. Your 4K video most likely isn't tak…

Compositor and ui framework that interact with them know that 120fps is not the target but that frame render time is, and know not to have active rendering contexts for static resources.

Chasing 120fps rendering here is the problem.

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

#79

Post by fxtentacle »

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…

Just checked and even without any additional setup JUCE is using CoreGraphics which is using Metal under the hood. So yes, the platform-specific renderer is using GPU.

Also, you can use OpenGL for GUI compositing, too, not only as a 3D context.

Post reply on HN