My rui library can render UIs at 120fps, uses similar SDF techniques (though uses a single shader for all rendering): https://github.com/audulus/rui Is their GPUI library open source?
Sadly I didn't see any links.
Leveraging Rust and the GPU to render user interfaces at 120 FPS
191–200 of 212 posts
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#192Erm, 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.
They only have themselves to blame, after the rewrites their forced their hardest advocates to go through, each one with worse tooling, dropping the UI designer, .NET Native and C++/CX along the way.
Native AOT still can't compile WinUI, while C++/WinRT is like doing ATL in 2000, while bug issues grow exponentially.
Only WinDev themselves, and WinUI MVPs, can still believe this is going somewhere.
The rest of us have moved on.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#193Earlier quoted context omitted.
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…
My hope is that we'll get a cross-platform toolkit that exceeds the quality of the best native toolkits (without relying on them). That would be great for cross-platform development, but the best thing would be that it would greatly lower the barrier to creating competing platforms. Imagine if Firefox OS was launched with a efficient toolkit instead of being web based for example.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#194"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…
> But that technique looks an awful lot like the 2018 GPU renderer from KiCad ;) And lastly, that glyph atlas for font rendering is only 1 channel? KiCad uses a technique using RGB for gradients so that the rendered glyphs can be anti-aliased without accidentally rounding sharp corners.
Is this stuff written down somewhere other than the code?
I use KiCad all the time and certainly never noticed this.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#195Nathan Sobo It should be noted that the main person behind Zed is Nathan Sobo, who created Atom while he was at Github, which is the basis of Visual Studio Code today. As such, I have high hopes Zed will be a much faster version of Visual Studio Code and am excited to see what him & his team make.
Well, he created electron for Atom. Atom itself was never a part of vsc. VSC was targetting the browser for a while before electron came along
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#196Earlier quoted context omitted.
Google has done a ton of work on GPU accelerated vector graphics too for Android and other platforms. Their skia library is pretty nice: https://skia.org/
Oops I forgot to mention that one. They also have a pretty interesting cross-platform GUI framework using it: https://flutter.dev/
And what was learned from Flutter has produced something I consider even more interesting: Compose UI (https://developer.android.com/jetpack/compose) and JetBrains' Compose Multiplatform (https://www.jetbrains.com/lp/compose-mpp/)
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#197Earlier quoted context omitted.
At least as far as dear imgui is concerned, it's an amazing library for dev tools but the accessibility story is dire and it has poor support for high quality typography, so it's a non starter if you're serious about good UI. This is not to diminish the quality work that went into the library, but I passed over it for those and other reasons. I used nuklear for a bit since its typography was extensible but in the end…
> a custom mixed immediate/retained library now with rich text and accessibility support. I'm always interested in learning about GUI toolkits that have accessibility support. What level of accessibility support does yours have? e.g. does it implement platform accessibility APIs, and if so, on which platforms? Is your library open source? If not, can I see it in action in any commercially available product? Thanks.
I haven't found good platform accessibility API bindings for C#, so right now it just has narration support, adjustable text size/contrast, and full keyboard navigation. I'm hoping that later on in my project's development process I'll have the budget to hire someone to try and fully integrate with the platform APIs - it's designed so it will be possible by pushing updates to the retained model.
The way it works is that it has an immediate mode API (see https://github.com/sq/Libraries/blob/0ca01d949e3df5fabb1440d... for a simple example of the API) and then under the hood it uses a lightweight retained-mode graph, which means that when it's more convenient you can just write more traditional classes and components. In practice most of the UI I've written for my main project is a mix of both models, like for example an editor popup window uses IMGUI-style API while the items in a virtual listbox are represented by a small custom component.
It does have a full imgui-style layout engine under the hood instead of doing retained-mode layout, so it's able to fully re-generate layout from scratch every frame, and to minimize page tearing there is a system where components can request a second relayout pass (typically used for things like text autosize).
Here's a more complex mixed-mode example from one of my development tools: https://gist.github.com/kg/6a6ba42d5019b546858a2b18751de019
Almost all of the on-screen elements in this footage are either immediate-mode or retained-mode UI using the library: https://www.youtube.com/watch?v=ey3FtFWxbhA
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#198Lots of negativity in here. I for one am excited about the prospect of an editor that is as responsive as I remember Sublime being back in the day, with the feature set I've come to expect from VS Code. An editor like this simply does not exist today, and betting on the Rust ecosystem is entirely the right choice for building something like this in 2023.
Here here. I backed Onivim hoping it was going to shine a light in the darkness, and it seemed promising, but ultimately was abandoned? I think, unsure.
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#199Why do we need a code editor with 120FPS support ?
Because competing code editors support it and thus lacking this capability would make your code editor seem unusually incompetent.
I am sorry but i tried googling and binging which code editor supports 120fps.
I also asked bing ai and it said it is not aware.
Could you please point me here as to what I am missing ?
Re: Leveraging Rust and the GPU to render user interfaces at 120 FPS
#200Earlier quoted context omitted.
Juce has a CoreGraphicsMetalLayerRenderer which I believe uses Metal to render CoreGrapghics primitives. And yes, I agree that JUCE will tesselate the splines into straight lines on the CPU. So technically, they are not fully rendered on GPU. But in practice, the slow rasterization is done on GPU while tesselation only has a negligible performance overhead. For example, I heard that UE4->UE5 removed the GPU tesselati…
> Juce has a CoreGraphicsMetalLayerRenderer which I believe uses Metal to render CoreGrapghics primitives. This class is part of a JUCE demo app, and you can read the source code to it if you want. [0] It uses CoreGraphics to render the graphics on the CPU, and then uploads it as a texture to the GPU so it can be used as a CAMetal layer. So, no, the graphics are still rendered on the CPU, with compositing being handl…
> I don't know why you're confidently saying something incorrect, it took me all of 2 minutes to find the source code and read it.
I'd say we just have different definitions of GPU-accelerated. Your position appears to be "purist" in the sense that almost all processing needs to happen on the GPU. But for me, if mostly static data is generated on the CPU once and then cached on the GPU and then processed on the GPU in all performance-critical contexts, then I would call that "GPU-accelerated" even if parts of the data preparation happened on CPU. That's also why I brought up the UE. They prepare the data on the CPU, then send it over to the GPU so that rendering in the real-time loop can happen only on the GPU. But the fact that the CPU prepared the data does not make it not-"GPU-accelerated" for me.
That said, can we agree that the ID2D1GeometrySink that JUCE uses on Windows is GPU-accelerated? Surely the Direct2D/DirectX drivers will do stuff on the CPU, but Microsoft says "Direct2D is a hardware-accelerated, immediate-mode 2-D graphics API" and they show very smoothly antialiased splines here while mentioning "Multisample Antialiasing", a GPU feature:
https://learn.microsoft.com/en-us/windows/win32/direct2d/dir...