| ▲ | ben-schaaf a day ago | |||||||
> 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. | ||||||||
| ▲ | 18 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. | ||||||||
| ||||||||