Comment by amelius
12 hours ago
> Just redraw the whole thing every frame. Great performance, simple, less bugs.
And in low power applications? Like on a smartphone?
12 hours ago
> Just redraw the whole thing every frame. Great performance, simple, less bugs.
And in low power applications? Like on a smartphone?
When the UI is highly dynamic/animated it needs to be redrawn each frame also in a 'retained mode' UI framework.
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).
The problem is that widgets still need to store state somewhere, and that storage space needs to be reclaimed at some point. How does the system know when that can be done? I suppose the popular approach is to just reclaim space that wasn't referenced during a draw.
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.
> How does the system know when that can be done?
At the earlist in the first frame the application UI description code doesn't mention an UI item (that means UI items need a persistent id, in Dear ImGui this is a string hash, usually created from the item's label which can have a hidden `##` identifier to make it unique, plus a push/pop-id stack for hierarchical namespacing.
> then the others will lose their state because of this
Once an item is visible, the state must have been provided by the application's UI description code, when the item is invisible, that state becomes irrelevant.
4 replies →
The job of the immediate UI is to just draw the things. Where and how you manage your state is completely up to you.
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.
5 replies →
> And in low power applications? Like on a smartphone?
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.