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.
What about when you're embedding your GUI into an existing application? or for use on an already taxed system? (Audio plugins come to mind)
What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?
The point of immediate mode UIs is not necessarily that there is no state specific to the UI, but rather that the state is owned by user code. You can (and, in these more complex cases, should) retain state between frames. The main difference is that the state is still managed by your code, rather than the UI system ("library", whatever).
Retained mode is more optimal when not much changes but if a lot of stuff changes at once it can be worse. So for real time applications like your audio example or games you want immediate mode. Retained mode is better for saving battery though or can be.
And in low power applications? Like on a smartphone?
When the UI is static and only needs to change on user input, an immediate mode UI can 'stop' too until there's new input to process.
For further low-power optimizations, immediate mode UI frameworks could skip describing parts of the UI when the application knows that this part doesn't need to change (contrary to popular belief, immediate mode UI frameworks do track and retain state between frames, just usually less than retained mode UIs - but how much state is retained is an internal implementation detail).
However ...
When you have a listbox of 10,000 rows and you only draw the visible rows, then the others will lose their state because of this.
Of course there are ways around that but it becomes messy. Maybe so messy that retained mode becomes attractive.
It seems you assume some sort of OO model.
> When you have a listbox of 10,000 rows and you only draw the visible rows, then the others will lose their state because of this.
Well keep the state then.
Immediate mode really just means you have your data as an array of things or whatever and the UI library creates the draw calls for you. Drawing and data are separate.
Doesn't make a difference. If the page is static, there is no redraw happening. If the page is dynamic, the redraw is happening at the frequency of the change (once per second, or once per frame, or whatever).
Whether you're doing a diff of the DOM or redrawing the whole DOM, typical pages (i.e. not two-sigmas past the median) aren't going to redraw something on every frame anyway.
If you just have a lot of text and a few rectangles and no animation, immediate mode would work well...
But if you have a lot of images, animation etc ... You'd anyway have to track all the textures uploaded to the GPU to not reupload them. Might as well retain as much of the state as possible? (Eg. QtQuick)
The more dynamic/animated an UI is, the less there's a difference between a retained- and immediate-mode API, since the UI needs to be redrawn each frame anyway. Immediate mode UIs might even be more efficient for highly dynamic UIs because they skip a lot of internal state update code - like creating/destroying/showing/hiding/moving widget objects).
Immediate-mode UIs can also be implemented to track changes and retain the unchanged parts of the UI in baked textures, it's just usually not worth the hassle.
The key feature of immediate mode UIs is that the application describes the entire currently visible state of the UI for each frame which allows the UI code to be 'interleaved' with application state changes (e.g. no callbacks required), how this per-frame UI description is translated into pixels on screen is more or less an implementation detail.
That depends on the kind of animations - typically for user interfaces, it's just moving, scaling, playing with opacity etc.. that's just updating the matrices once.
So you describe the scene graph once (this rectangle here, upload that texture there, this border there) using DOM, QML etc..., and then just update the item properties on it.
As far as the end user/application developer is concerned , this is retained mode. As far as the GPU is considered it can be redrawing the whole UI every frame..
...any tiny change like this will trigger a redraw (e.g. the GPU doing work) that's not much different from a redraw in an immediate mode system.
At most the redraw can be restricted to a part of the visible UI, but here the question is whether such a 'local' redraw is actually any cheaper than just redrawing everything (since figuring out what needs to be redrawn might be more expensive than just rendering everything from scratch - YMMV of course).
Something like a lot of text ? Probably easier to redraw everything in immediate mode.
Something like a lot of images just moving, scaling, around? Easier to retain that state in GPU and just update a few values here and there...
This is a great attitude to have. Keep up the great work.
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
the 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/...
I’m going through similar “hell” (my words). I just wanted some simple Ui for WebXR but the dipshits that designed XR for the web fucking threw all the web parts out so you can not just put up a few simple html elements up in XR. You have to write your own UI library from scratch. It’s so mind bogglingly stupid.
In any case, having to write it, like you I started small and the it quickly ballooned because even simple things get complicated quickly, all the while I’m cursing under my breath there is a perfectly unable system but TPTB chose not to offer it >:(
WebXR sounds like a different beast entirely. do you have to write your own rendering backend in WebGL for that?
But, as an example of similar complexity. I hacked together the first Ui I needed. It was 6 buttons and a slider. Then I realized I needed two more Ui panels and started to write more real Ui classes to abstract stuff out and, it just starts getting more and more complicated.
A slider needs to “capture the pointer”, meaning as you drag it, if to drag past the end of the slider and the pointer is now over another widget the events should still go to the slider. It’s not hard to implement, it’s just frustrating for me that I don’t actually want to write it. I just want to make my panel and if I could just use html id be done. Instead I’m spending my limited free time making this ui system. I don’t have that much and would be much further along in my actual goals except for this road block