> Just redraw the whole thing every frame. Great performance, simple, less bugs.
And in low power applications? Like on a smartphone?
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.
This is a bit oversimplified. For instance Dear ImGui needs to store at least the window positions between frames since the application code doesn't need to track window positions.
https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...
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.
What happens when the item moves out of view, e.g. because the user scrolls down?
State should be preserved, because the user might scroll back up.
E.g. pseudocode:
for (firstVisibleItemIndex .. lastVisibleItemIndex) |itemIndex| {
ui_list_item(itemIndex, listItemValues[itemIndex]);
}
How does the immediate mode system know that the corresponding state can be deleted too?
Does the system provide tools for that or does the burden lie on my application code?
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.