you can cache layouts with immediate mode libraries. in terms of scaling, it really depends - if you have many components updating at once, the benefits of retained mode libraries are diminished if not reversed. when people create demos of 10,000 list elements and updating a single one, it's basically designed as a best case scenario for retained mode. try updating the entire list...

but i can make strong claims about the benefits of not needing to duplicate your state inside of your ui framework. that alone removes an entire category of work, and i would argue scales better from a conceptual/dev standpoint.

▲

ben-schaaf a day ago | parent [-]

> you can cache layouts with immediate mode libraries

There's all sorts of caching you can do with immediate mode; like you said, caching the layout in a large list. The end result is the same as retained mode, with all the same complexities. Might as well skip reinventing the thing.

> try updating the entire list...

If you're comparing like-for-like, whether you're doing layout for the entire UI in immediate mode or retained mode shouldn't make a big difference. You're doing the same calculations after all.

> but i can make strong claims about the benefits of not needing to duplicate your state inside of your ui framework

I've found it's often not necessary to duplicate state in the UI framework; you can frequently make UI controls the owner of the state.

▲

17 hours ago | parent | next [-]

[deleted]

▲

slopinthebag a day ago | parent | prev [-]

to some extent retained mode is a cache invalidation problem. imgui's sidestep this, except for a constrained set of cases where building the ui requires doing a lot of work, in which case a simple, bespoke cache can be used - to me this is far simpler than trying to wrangle your entire application through a generalized state cache abstraction. especially since doing so generally requires you to deeply adopt the UI framework's abstractions into your application code, regardless if it's a good fit or not - like you said, you can avoid duplication, but the tradeoff is massive coupling.

i think a glaring red flag with retained mode ui's is how slow they are. there is a reason they put so much effort into granular reactive updates - they're just way too slow otherwise. resize retained mode ui windows and the fps drops to like 2. meanwhile in an imgui, it doesn't matter if you're rendering 1000 buttons and then need to render 1000 dropdowns, the work is roughly identical. this means big problems for a retained mode system. this seems like a massive issue to me - the system is so slow, it's only considered "faster" than imgui (debatable) when it doesn't actually do much. but we want ui's to scale with interactions, not depend on minimal changes in order to recover acceptable performance.

	▲	ben-schaaf 10 hours ago \| parent [-]
		> resize retained mode ui windows and the fps drops to like 2 This just isn't true? Every desktop application I use uses a retained mode UI and most of them resize smoothly. Most of the ones that don't are electron. I genuinely don't understand how you can make this claim right after agreeing with me that the only difference is the caching. You can't seriously be claiming that by just adding a layout cache you lose 30x performance?