Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

101–110 of 148 posts

Re: I Switched from Flutter and Rust to Rust and Egui

#101
post #95

I use Egui, in a game-type application. I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time. Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get t…

Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit.

I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors.

Re: I Switched from Flutter and Rust to Rust and Egui

#102
post #19

Earlier quoted context omitted.

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although t…

I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.

Kind of off topic, but a protein viewer in Rust sounds really interesting! Is the source code available? I'd love to poke through it (understandable if not though).

Re: I Switched from Flutter and Rust to Rust and Egui

#103

Earlier quoted context omitted.

I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.

Kind of off topic, but a protein viewer in Rust sounds really interesting! Is the source code available? I'd love to poke through it (understandable if not though).

Yep - https://github.com/David-OConnor/daedalus/

Re: I Switched from Flutter and Rust to Rust and Egui

#104
post #101
post #95

I use Egui, in a game-type application. I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time. Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get t…

Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit. I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience mig…

> I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors.

To some extent, yes. Here's an example.[1] So many features have been added that the unit tests were taking too long. So tests were switched to use a faster allocator. That won't even compile for cross-compilation from Linux to Windows.

Because tests won't run, chasing down other cross-compilation bugs got much harder.[2]

This is the price of feature bloat. Core stuff is breaking and not getting fixed as cool features are bolted on. Currently, 799 open bugs. The technical debt is building up.

[1] https://github.com/emilk/egui/issues/7033

[2] https://github.com/emilk/egui/issues/6847

Re: I Switched from Flutter and Rust to Rust and Egui

#105
post #5

I still prefer good old GUI frameworks with WYSIWYG designers.

I miss WYSIWYG designers so much. I used to use them to make small apps all the time because, while I'm a good programmer, I'm awful at trying to lay out a UI in code. WinForms in Visual Studio used to be great for people like me!

Re: I Switched from Flutter and Rust to Rust and Egui

#106
post #61

Earlier quoted context omitted.

Immediate mode only describes the interface.

Does it? I had the impression that the lack of double buffering would imply a more direct access, this the "immediate" in the name.

Yes, "immediate" refers just to the API. Source: [1]

[1]: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

Re: I Switched from Flutter and Rust to Rust and Egui

#108

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs

Since others are sharing Rust GUI libraries, I’ll mention Slint [ https://slint.rs ] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

One of the things I appreciate a lot about Slint is that you guys are, as far as I can tell, the only GUI toolkit devs who thought to include a menu widget. Desktop applications need a menu bar! So that means that, for me at least, Slint is the only viable option out there.

Re: I Switched from Flutter and Rust to Rust and Egui

#110
post #101
post #95

I use Egui, in a game-type application. I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time. Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get t…

Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit. I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience mig…

Two-pass rendering was considered and rejected by the Egui developer. What they have is sort of one and a half pass rendering. Sometimes, things are wrong on the first draw, but correct on the next draw because info is retained from the previous frame.

Back in 2023, this created a bug where a text box was misaligned on alternate frames.[1] Amusingly, I tried to capture a video of this, and the 30 FPS video looked perfect, because it was capturing only alternate frames of 60 FPS refresh.

Bugs in layout can be very strange in Egui.

[1] https://github.com/emilk/egui/issues/2810

Post reply on HN