Live data from Hacker News

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

zed.dev

201–210 of 212 posts

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

#201

Earlier quoted context omitted.

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

I think you might like AccessKit [1], once we figure out the best way to provide reasonably efficient .NET bindings. Basically it's an abstraction over the platform accessibility APIs, written in Rust. And it's specifically designed to be usable in immediate-mode GUIs (the first completed toolkit integration was in egui, a Rust immediate-mode GUI). You push tree updates, which can be full or incremental, and AccessKit retains the accessibility tree.

[1]: https://github.com/AccessKit/accesskit

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

#202
post #185

Earlier quoted context omitted.

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

60 is the new 30. Was amazed at how good my latest iPhone feels with 120hz scrolling. It's like magic.

I thought moving to 144 Hz monitor made sense just for gaming, but now on 60 Hz monitor just moving the mouse on desktop feels as if the PC is struggling

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

#203

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 aren't talking about the same thing they are and you aren't talking about a scenario that exists. 8k is still exotic and no one is driving any desktop off of a video buffer going from main memory through a CPU.

We've literally got an 8k screen in the office and 4k is becoming increasingly common. Not only is this a scenario that exists it's one I've personally experienced and fixed.

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

#204
Beyond the rendering which as noted is nothing that hasn't been done before (in general) the inherent OT/multi user + tree sitter functionality is something that entices me.

I'm surprised nobody pointed out lite/litexl here either it's rendering of ui is very similar (although fonts are via a texture; like a game would) and doesn't focus overly on the GPU but optimises those paths like games circa directx9/opengl 1.3

There are great details of the approach taken with lite at https://rxi.github.io

Lite-xl might have evolved the renderer but the code here is very consumable for me.

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

#205

Earlier quoted context omitted.

You aren't talking about the same thing they are and you aren't talking about a scenario that exists. 8k is still exotic and no one is driving any desktop off of a video buffer going from main memory through a CPU.

We've literally got an 8k screen in the office and 4k is becoming increasingly common. Not only is this a scenario that exists it's one I've personally experienced and fixed.

Your 8k screen is run purely off of the CPU drawing to a frame buffer?

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

#206

Lots of people nit-picking the 120 FPS but I think Zed looks super promising. The native support for collaborative editing looks fantastic, and I'm excited to try it out. Curious if you guys have thought about VR / AR possibilities with GPUI?

That would be interesting in VR to have syntax highlighting that moves variable names towards the viewer, or puts context menus with possible methods of some object above. Would probably just be stupid gimmick, but I want to see somebody do it :-D

I tried this, using https://makepad.dev our GPU accelerated UI and renderstack. And unfortunately it wasn't a great experience. Text popping forward for whatever reason is not really an improvement (i tried indent depth, syntax highlighting reasons, cursor behavior). Maybe 'veeeeery' subtly could do something, but otherwise you dont want it to break visual symmetry as we are used to

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

#207

Earlier quoted context omitted.

> KiCad uses a technique using RGB for gradients so that the rendered glyphs can be anti-aliased without accidentally rounding sharp corners. This is known as a “multi-channel signed distance field”, or “msdf”. https://github.com/Chlumsky/msdfgen

Do you know any text editor that uses it for font rendering?

I used to use it, but its extremely font and glyph-sensitive wether or not it works. And if it doesn't work there is no easy fix (or ability to recognise it nonvisually)

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

#208
post #189

Earlier quoted context omitted.

I know that in Windows 10+ and on UWP apps, requesting a fullscreen swapchain straight up crashes and tells you "nope, you're going to go through the compositor". But yes, alt-tabbing Source games was an exercise in patience.

Is that disabled for programs targeting older OS versions? Or are you saying that the new behavior is only for UWP apps? Because that sounds like it would break a lot of old code.

Sorry, hadn't seen that response: yes, it's only when you opt in to UWP that it causes crashes. However, even if you didn't, Windows lies to you. If you ask for FSE (Full Screen Exclusive), it'll say alright buddy, and give you a Full screen that goes through DWM. I believe they have an article on that somewhere on the direct X blog called full screen optimizations, or something along those lines, that explains it.

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

#209
post #124

Earlier quoted context omitted.

Afaik egui isn't doing any kind of the fancy GPU based 2D graphics this blog post is about though.

have a look at what egui creator (and his team) been doing with rerun [0] Egui seems well suited to render even tens of thousands pointcloud with wgpu backend. [0] https://www.rerun.io/

Rerun dev here :). Yes, we're using egui with its wgpu backend! As someone else pointed out it is backend agnostic - it essentially generates triangles & textures in GPU friendly way and passes those down to a backend implementation.

All the visualizations like the 3D scenes with point clouds etc. are rendered with our open-source in-house renderer ("re_renderer") which itself is then passing wgpu surfaces/commands to the egui wgpu backend that composites everything together then.

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

#210

You cannot see at 120 fps.

You're right, you can't see at 120 fps, because that's not how human vision works. You can't see at any fps. However the more fps there are, the sooner you get the information, and so regardless of the lag on your end (the biology behind the eyes, the brain, and the connection between them), you still add some delay coming from your computer.
Post reply on HN