I actually use a very similar paradigm successfully in a game [1] whose (immediate-mode) UI is fully responsive. I allow more operations than just cutting to do that, but the basic idea seems to be the same. The code may look like a bit of a mess at a first glance [2], but I still find it easier to work with and make it do what I actually want with some very basic vector maths, than with the layout-container rules of most UI frameworks.
Retaining state is a pain and causes bugs. Trying to get fancy a la react and diffing the tree for changes makes not sense. That was a performance hack because changing the DOM in JS used to be slow as hell. You don't need that.
Just redraw the whole thing every frame. Great performance, simple, less bugs.
Had a similar itch during my game development with libgdx, and had almost same architecture eventually
I found that I have two different ways to construct UI layout , from top down, and from down to top, those could be contradictory, wonder how one could solve this, seems like common problem in all frameworks that I saw, like flutter just fail with error on screen if it can't solve restrictions in such conflict , others just show jiberish
Lots of confused comments here about immediate vs retained GUIs. Immediate-mode is an API-design, not an implementation detail. All Immediate-mode GUIs retain data, and for that reason they each have their own APIs for retaining data in various capacities. Usually something really simple like hashing for component-local state.
9 comments
[ 15.2 ms ] story [ 985 ms ] threadthe API is a very simple one where you slice parts off an initial Rect. the only feature it provides is that it tracks (x, y, h, w) for you.
it doesn't work well with intrinsic sizes - it's more of a top down, fixed size thing.
[1]: https://fruitsandtails.fghj.cz/
[2]: https://codeberg.org/spiffyk/FruitsAndTails/src/branch/main/...
This is a great attitude to have. Keep up the great work.
Retaining state is a pain and causes bugs. Trying to get fancy a la react and diffing the tree for changes makes not sense. That was a performance hack because changing the DOM in JS used to be slow as hell. You don't need that.
Just redraw the whole thing every frame. Great performance, simple, less bugs.
I found that I have two different ways to construct UI layout , from top down, and from down to top, those could be contradictory, wonder how one could solve this, seems like common problem in all frameworks that I saw, like flutter just fail with error on screen if it can't solve restrictions in such conflict , others just show jiberish
But less if you had spent a fraction of that time just learning about established solutions and hacking around those
(ironic indicator: the first button on the page reflows on first click, so an example of bad UI)