Live data from Hacker News

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

zed.dev

61–70 of 212 posts

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

#61

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.

What about the winrt api?

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

#62

Earlier quoted context omitted.

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.

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.

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

#63

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.

Why not just use DirectX/*GL for those regions that need it and stick with platform UI for the rest? Blitting API still works just fine if you're drawing combo boxes, no?

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

#64
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 but nothing happens in response to button taps or text insertion. It is the only way RN was going to work on lower end hardware though so probably is the right solution if you assume running react everywhere is a good idea.

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

#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.

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

#66

Earlier quoted context omitted.

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.

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.

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

#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 second, and your editor doesn't.

And the limited resource is not the gpu itself but the nearby onboard memory is a scarce resource on its own. I'd be real mad at a software that prevents me to multitask.

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

#68

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

It’s hard to make a cross-platform UI that way.

That is what wrappers and platform plugins are for, no need to build a full blown API from scratch.

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

#69

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.

You can use ID2D1HwndRenderTarget::DrawBitmap or ID2D1RenderTarget::DrawBitmap instead.

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

#70

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.

If you're using BitBlt instead of Direct2D in anything post Vista, you're holding it wrong.
Post reply on HN