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

111–120 of 212 posts

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

#111

Post by ben-schaaf »

jcelerier wrote: post #102
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.

But when you do software rendering you don't need to redraw the entire frame buffer, just the parts that changed, which can be very small even at 8k - e.g. the box of a checkbox being switched

Scrolling requires redrawing most if not the whole framebuffer.

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

#112

Post by ben-schaaf »

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.

The other latency that matters is how long it takes to draw each frame when scrolling through the code, which is usually most if not all of the framebuffer.

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

#113

Post by nottorp »

as-cii wrote: post #57
nottorp wrote: post #54

I don't understand. Why would you need to render a user interface constantly at 120 fps, instead of just updating it when something changes? Laptop batteries last too long these days? Electricity too cheap?

Hey nottorp. Antonio here, author of the post. Zed and GPUI use energy very judiciously and only perform updates when needed. The idea is that we can render the whole application within ~8ms, and that shows everywhere: from typing a letter to scrolling up and down in a buffer. However, if the editor is sitting there idle, we won't waste precious CPU cycles. Thanks for the feedback!

Yeah, might want to edit the title a bit. Or not, considering these concepts are getting lost.

I mean, the win16 api from ages ago had support for invalidating specific screen regions etc. It probably got lost somewhere in the transition to javascript...

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

#114

Post by pjmlp »

pornel wrote: post #104
pjmlp wrote: post #68

Earlier quoted context omitted.

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

Such solutions are often in tension between using only the lowest common denominator, and the code having different implementation for each platform anyway. For example, their editor has tabs for editor buffers. Cocoa has a static tabbed widget, which has wrong look and odd UX for this. Cocoa also has a tabbed window type, which isn't a widget you can control. I imagine it'd be hard to abstract that away to work cons…

There are no perfect solutions, but there is possible balance where OS features are abstracted into higher level concepts, not 1:1.

For very contrived example, the cross platform settings panel widget exposes the business API required for settings in general, while the platform specific code takes care of using the host platform concepts to display and manage application specific settings.

While it is more work than lowest common denominator approach, it is still much less than re-inventing the wheel.

As proven by mobile OS platforms, there are still hope for native toolkits.

Lets see how much long the Web will hold, now that the revenge of plugins is here thanks WASM.

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

#115

Post by ben-schaaf »

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…

> 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 like Google Chrome.

Windows uses GPU-based rendering in most/all of their GUI frameworks. Chrome also makes heavy use of hardware acceleration. Rendering performance isn't left to the window manager. If you're making your own GUI this is exactly the kind of stuff you need to do to make it fast.

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

#116

Post by pjmlp »

flohofwoe wrote: post #100
pjmlp wrote: post #66

Earlier quoted context omitted.

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.

The industry has moved beyond past decisions for a reason, that is the point.

Some of them keep being rediscovered in endless loops of fashion.

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

#117

Post by meindnoch »

fxtentacle wrote: post #79
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…

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.

CoreGraphics doesn't use Metal. You're confusing it with CoreAnimation.

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

#118

Post by ben-schaaf »

avereveard wrote: post #91
TiredOfLife wrote: post #81

Earlier quoted context omitted.

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 r…

That's already what they're doing: https://news.ycombinator.com/item?id=35080427

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

#119

Post by bobajeff »

ohgodplsno wrote: post #109
bobajeff wrote: post #106

Earlier quoted context omitted.

Thanks, I'm reading the paper* linked to on that site explaining the technique used in the library. It's encouraging me more to pursue implementing a 2D render on the GPU. I'm also inspired by a recent talk about gkurve**. * https://jcgt.org/published/0006/02/02/ ** https://m.youtube.com/watch?v=QTybQ-5MlrE

Do note that as far as I know, this technique is patent-encumbered, at least in the US.

Thanks. I wonder what the patents cover. With all the work going into 2D rendering on the GPU I'd imagine others discovering similar methods.

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

#120

Post by kridsdale1 »

meindnoch wrote: post #117
fxtentacle wrote: post #79

Earlier quoted context omitted.

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.

CoreGraphics doesn't use Metal. You're confusing it with CoreAnimation.

I concur.
Post reply on HN