You cannot see at 120 fps.
Leveraging Rust and the GPU to render user interfaces at 120 FPS
141–150 of 212 posts
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#142Earlier 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? 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.
Some people will also any available lib for games, doesn't mean it's "widly used". As for such a plugin, it's more like wishful thinking for getting gaming customers than actually something that sells in any amount to write home about.
The kind of games some tint amount of people make with JUCE is like this: https://ankuznetsov.wixsite.com/jucegames and even those are few and far between.
In any case, nowhere even close to "widly used" in gaming. Nor moderately used, or even low use.
"Few and far between users of JUCE for games, and even at that almost all of them using it for hobby casual game projects" is an accurate description.
JUCE does dominate in audio VST/AU fx/instruments GUIs though...
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#143"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…
Meanwhile, the gaming world is moving to HTML/CSS/JS for game UI in many cases.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#144The 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…
> 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.
No we didn't. We had nothing close to that in the 90s.
Typing was responsive, but that's not anywhere close to 60fps and a very small region to update to boot (120wpm = 600 keys/minute = 10 keys/s, or 10fps). Scrolling benefits from 60fps+, but in the 90s scrolling jumped by lines at a time because it couldn't do anything better.
You need a GPU to keep up with smooth scrolling at modern resolutions. But this also shouldn't be a surprise. What the article talks about is bog standard stuff for all current UI toolkits. It's what mobile platforms like Android have been doing for a decade now.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#145Erm, native WinUI apps are GPU accelerated and render at vsync.
Nobody loves native WinUI, not even Microsoft.
Which is kind of a shame. But it's the result of years of product management neglect as well as the pull away from desktop UIs to web UIs.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#146Earlier quoted context omitted.
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
That's even weirder why would they redraw the whole application on a character change
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#147Erm, native WinUI apps are GPU accelerated and render at vsync.
So is everything written in Apple native UI frameworks since 2009.
And Android and QT and GTK and Chrome and Firefox and etc...
The article is talking about the same generic hybrid GPU-accelerated rendering architecture that everything uses. Seemingly the only "new" part is "in Rust!"
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#148You cannot see at 120 fps.
Check out https://www.testufo.com/ on a 120Hz display; the higher FPS is absolutely perceptible.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#149First, this looks awesome. Can't wait to try zed.
Second, forgive a naive question since I know nothing about graphics, but would the method described in the article perform better than Alacritty + Neovim?
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#150I 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?
[deleted]