Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emerging Rust GUI libraries in a WASM world

monadical.com

Post reply on HN
Print view View original

161–170 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#161

Post by Freaky »

flohofwoe wrote: post #103
osener wrote: post #74

Earlier quoted context omitted.

What makes egui so fast? I thought immediate mode GUIs have a convenient API at the expense of unnecessary redraws and lower performance. Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.

This demo produces only a handful of draw calls to the GPU, and even though those draw calls can have hundreds of thousands of triangles, that's still as efficient as it gets. I guess that egui works similar to Dear ImGui: only (font) texture changes and clip regions (e.g. scroll areas) require a new draw call, and that's typically just a handful to a few dozen draw calls even for complex UIs. For long lists, Dear Im…

> Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.

An egui ScrollArea can request only visible rows from a callback using show_rows:

https://docs.rs/egui/latest/egui/containers/scroll_area/stru...

Re: Emerging Rust GUI libraries in a WASM world

#162

Post by eslaught »

josephg wrote: post #139
eslaught wrote: post #44

Earlier quoted context omitted.

In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo). I wonder if your experience is different? As best I've been able to tell, right now you have to make a choice between (a) fast an…

What domain are you working in? Smoothly rendering 3k rectangles isn't a common use case for UI libraries, so I'm not surprised they perform poorly. They generally aren't optimized for that. The normal answer for weird, high performance rendering like that is to just use opengl or something and program against the GPU directly. 3d rendering contexts can render millions of rectangles on modern hardware without breakin…

Like I said in my top comment, it's a profiler. I need to consume logs from distributed applications (on possibly tens of thousands of nodes) and render them in as coherent a fashion as possible.

Going to 3d rendering via OpenGL / WebGL was one of the options I considered. But honestly, this is a boatload of complexity. Why do I need to pick up a full 3D rendering library just to draw rectangles on the screen? Plus, consider: the slot viewer (where the rectangles are shown) still needs to draw some UI components (e.g., on hoverover). I still need that UI integration there, even if it's not as performance-sensitive. So I end up needing something along the lines of egui anyway.

I definitely understand that not all UI libraries are going to be optimized for this. But I was surprised that it wasn't easy to e.g. get a high-performance canvas dropped into libraries that specifically advertised themselves as high-performance.

Re: Emerging Rust GUI libraries in a WASM world

#163

Post by Klonoar »

iudqnolq wrote: post #75
Klonoar wrote: post #11

Earlier quoted context omitted.

>That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". That's... entirely wrong and not necessary to paint swathes of developers like. Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms. Jus…

Can you give an example of a real, shipped app where the majority of the GUI is written in Rust? I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust. This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite di…

A number of apps in the GNOME ecosystem use the Rust GTK bindings (e.g, Fractal).

Re: Emerging Rust GUI libraries in a WASM world

#164

Post by danShumway »

chrismorgan wrote: post #21
CJefferson wrote: post #6

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page). Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.

Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice): The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-p…

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem."

The web does have an accessibility API. It's called the DOM.

What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users and a much laggier less-featured app for users using the accessibility API, because it forces you to always have the accessibility API turned on. It forces you to treat the accessibility API as your default rendering target (and allows you to occasionally make something inaccessible by embedding a canvas element inside of that UI for one or two parts of your app.

And if you can't develop a fast app using the accessibility API, then having a toggle to turn that layer off is not really a solution for that problem. I'm very glad AccessKit exists, it's better than nothing, but that doesn't mean the apps that are using it should be proud of themselves.

Re: Emerging Rust GUI libraries in a WASM world

#165

Post by danShumway »

eslaught wrote: post #159
danShumway wrote: post #156

Earlier quoted context omitted.

Should you be changing 3K rectangles of your interface at 30fps? This seems like a very narrow use case that should be restricted to using Canvas with very specific parts of the application. Maybe you have graphs/charts that need that kind of rendering effect. Great, use Canvas for them, they're not accessible anyway. But if something like your main user controls are running into that problem, I feel like something h…

I don't know if you noticed, but my test has on the order of 10 billion rectangles. Only about 80k are drawn on the screen at once because I do very aggressive culling. To be honest, I'm not sure Canvas can handle either part of this: either drawing 80k rectangles at 60 fps or culling so that the other 10 billion don't need to waste CPU cycles. It requires a very tight integration with the UI library to make sure we…

> I'm not sure Canvas can handle either part of this

To be clear, WebGL/WebGPU is still using Canvas. You're not using the 2D api stuff, but that's just a high-level API on top of Canvas. You're still rendering to Canvas.

> I don't know if you noticed, but my test has on the order of 10 billion rectangles

Why? I've built apps like this before. Your choice is not "abandon the DOM" or "have zero performance." You can have most of your interface in the DOM and use Canvas (again WebGL/GPU is still Canvas) for specifically the parts of your app that wouldn't be accessible anyway (mainly charts).

It does not require tight integration with the GPU to render the sliders on the left hand side of the screen in this demo. No one is saying that you need to render your charts in DOM. We're wondering why you got rid of `ul` elements.

Re: Emerging Rust GUI libraries in a WASM world

#166

Post by danShumway »

danShumway wrote: post #155
eslaught wrote: post #39

Earlier quoted context omitted.

I have no beef with deferred mode GUIs except that I have yet to see one with the performance characteristics I need. For what it's worth, egui does have an accessibility layer. I haven't gone to any particular effort to wire it up yet (besides what you get by default): https://github.com/emilk/egui/issues/167

This is what I don't get: if you have an accessibility layer that is fully usable, that means you have the capability to describe your user interface using only speech/text. So what are you doing that couldn't be performant in the DOM? Because any kind of fast updates that you're doing with a lot of triangle that are too fast to render into an XML tree are also going to be happening too fast to describe with a screen…

People always get upset about this kind of thing, but it's very obviously true.

If you are updating thousands of rectangles in your UI at 30/60fps, it is impossible for you to fully convey the same amount of information that is changing visually to a screen reader.

Either your interface can be described using pure text, or it can't. Either I could use your interface by closing my eyes and having someone describe it to me, or I can't.

Re: Emerging Rust GUI libraries in a WASM world

#167

Post by sophacles »

mcluck wrote: post #4

> GUI in Rust progresses with unprecedented speed – 3 months in Rust GUI-land is like 3 years in the mortal world. areweguiyet.rs was started almost exactly 5 years ago. That means it's been about 60 mortal years and we still don't have a definitive solution to GUIs.

C was started 50 years ago, and we don't have a definitive solution to GUIs there either. I'm not sure what your point is.

Re: Emerging Rust GUI libraries in a WASM world

#168

Post by Firfi »

ljsb wrote: post #108

I hope it's OK to add a shameless plug for my Rust WASM framework, Silkenweb [0]. It's similar to Leptos and Sycamore in that it's signals based, but I've put a lot of effort into making it ergonomic without resorting to a macro DSL. It supports all the usual things like SSR and hydration, along with a few nice extras like scoped CSS. [0] https://github.com/silkenweb/silkenweb

Author here! I've added it to my TODO list and will update the article at some point coming week or two. Love how the library looks like - thank you for the link!

Re: Emerging Rust GUI libraries in a WASM world

#169

Post by danShumway »

waboremo wrote: post #138
mwcampbell wrote: post #136

Earlier quoted context omitted.

Lead developer of AccessKit here. I know it won't be a panacea, particularly for the non-screen-reader-related problems you point out. And about the performance problem, there's probably no getting away from the despised "enable accessibility" button. But if these types of applications are going to exist despite our wishes to the contrary, then I have to do what I can to make them accessible. It could be the differen…

Good intentions, but this leads people to create even more apps that they then proudly proclaim are just as accessible as alternatives because of AccessKit. It's a bit of a catch-22.

It's far better that AccessKit exist than that it not.

That being said, yeah, there are people in this very comment section saying that of course egui is accessible, it supports AccessKit. So it's not really theoretical, any attempt to close the gap with AccessKit is going to be used by people as an excuse to build inaccessible applications. That's already happening in this comment section right now.

But that doesn't mean that AccessKit shouldn't exist it's just... one of the downsides to reducing the number of entirely inaccessible apps. It's a partial fix for a bad situation, and it's good for devs to use it if they have to, but it's far better for devs not to need to use it.

Re: Emerging Rust GUI libraries in a WASM world

#170

Post by kps »

josephg wrote: post #22
eslaught wrote: post #2

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the…

Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.) I sincerely hope the web as a whole doesn't move in this dir…

> I sincerely hope the web as a whole doesn't move in this direction.

I'm not happy about it, but I think it will.

> The inspectibility of the DOM is one of the web's greatest strengths.

Not if you're pushing ads.

Post reply on HN