If you want a simple, one pass layout that super fast, you use the fast-and-dumb-on-purpose-engine. If you want a fancy dynamic scaling layout with breakpoints and blah blah blah, you use the whole-damn-browser-engine.
Thinking along the lines of geometry managers in Tk. Or wxWidgets Sizers.
https://wiki.tcl-lang.org/page/Geometry+Managers
Maybe I am missing something basic and this won't work/doesn't address the problem.
But maybe there's good prior art to learn from here.
If your UI lib is not doing scrolling text boxes with line wrap, can't have different alignments, doesn't have a solution for context menus, then what good is it?
I remember that I essentially had to code it myself a few years ago, but I can't remember if it was egui or imgui.
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. People love it because it's lightweight and fast.
2. More and more people use it.
3. Feature requests start to roll in.
4. It becomes bloated and slow.
5. People get fed up and start to hate it.
6. Create a new ticketing system and return to step 1.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.
Did you just search for bugs containing "CPU usage" and not actually read it?
Originally HTML was one-pass. Until they added tables. And tables require at least two passes to lay out.
There's only so far that you can take one pass rendering
Right. The whole point of Egui was supposed to be that it was a game renderer, a text and button overlay on the game graphics. Not the entire screen. That's why it's immediate mode. It's supposed to redraw on every game frame. Most UI programs don't need or want that.
But it was better at the basics than anything else in Rust, so it caught on for routine non-game programs. And here we are.
Seriously. The main tale I think is how awful Rust's story on GUIs are such that most Rust users prefer a pretty awful GUI library because it's somehow better than everything else. And that's coming from someone who's favorite language is easily Rust.
In other words, with default styling you have to calculate natural widths of every cell in the whole table before you can begjn layout out even the first cell of the table.
There are style settings you can use which change this, and allow layout of early cells or rows to complete without depending on later cells.
(Also the height of each row can depend on the height of the content of every cell in the row. But that's local to each row so it's a relatively small dependency.)