Hacker News Reader

Comment by amelius | Hacker News Reader

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.

View on HN

> 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.

> 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.

Once the item becomes visible, the application's UI code provides the item's state again.

E.g. pseudocode:

    for (firstVisibleItemIndex .. lastVisibleItemIndex) |itemIndex| {
        ui_list_item(itemIndex, listItemValues[itemIndex]);
    }

For instance Dear ImGui has the concept of a 'list clipper' which tells the application the currently visible range of a list or table-column and the application only provides the state of the currently visible items to the UI system.

Ok, but now items 1,000 through 10,000 are deleted from the data container.

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?

Same way as for regular ui items, if the application's ui code no longer "mentions" those items, their state can be deleted (assuming the immediate mode tracks hidden items for some reason).

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.

> 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.

Well, I can keep the state, but a retained mode UI model does it for me :)

But 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.

But why do you think retained mode was invented if "just drawing" is so simple?

Here's an informative explanation in the DearImgui library which chose this approach.

https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

Reply on news.ycombinator.com