4 ms·
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.
by cardanome 8mo ago
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.
- flohofwoe 8mo ago> The job of the immediate UI is to just draw the things. Where and how you manage your state is completely up to you. 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.
- amelius 8mo agoWell, I can keep the state, but a retained mode UI model does it for me :)
- lioeters 8mo agoBut then you have state in two places, user code and the retained-mode GUI framework, which need to be synced - that's where complexity creeps in. Immediate mode removes that redundancy and makes things simpler in many situations. It depends on your preference and what you're doing too, which approach suits better.
- amelius 8mo agoBut why do you think retained mode was invented if "just drawing" is so simple?
- lioeters 8mo agoHere's an informative explanation in the DearImgui library which chose this approach. https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...