Earlier quoted context omitted.
Do you have any proof of this or just a gut feeling? Immediate mode guis do cache stuff, at least Dear ImGUI, one of the most popular Immediate mode guis caches. Further, at least in my mobile usage almost everything I do with my phone re-draws the entire screen. The #1 thing to do is scroll through content. There's very few apps I run where only some tiny thing is getting updated. Maybe my music player. I don't thin…
Once you’ve introduced a state based caching and differentiation layer, you’re introducing retention and are entering into hybrid UI. If you don’t have sufficient caching layers to figure out when something has to update, you’re drawing too often killing battery. Maybe there are fewer purely immediate mode UI libraries today, which muddies the discussion though. On the note of the apps used, I would say the vast majo…
You say this with zero proof. Checking 100s of widgets to see if they overlap, updating their damage boxes, drawing the parts of the ones that got overlapped, computing clip bounds for each one, switching graphics contexts, to do all that adds up to "killing the battery"
Retained APIs are like using a binary tree where an Immediate mode GUI is like using a vector. CS principles say the tree should be faster as insert and delete are in O(1) but in reality, cache misses and similar things kill all the perf you supposedly gained by over engineering the solution.
The same is often true of retained mode GUIs vs immediate, especially with all the transparency effects in modern UIs. Computing the minimal amount of parts can requires a ton more CPU than just drawing.
As far as caching = retained, no. The difference between an Immediate Mode and a retained mode API is if you, the user, have to create and maintain a tree of retained API widgets. No one is going to implement an immediate mode API and try to have a text widget that word wraps and expect it to have to compute all the word wrapping every frame.