[mooman219]

This is really reads like someone trying to sell you something. I've done work on frameworks for both immediate mode and retained mode GUIs. They both absolutely allocate memory behind the scene. There absolutely is state being marshaled around. Caching commonly used state is important. Performance can be bad and great in both. You're really just subscribing to different sets of opinions

[TazeTSchnitzel]

Any moderately complex “immediate mode” GUI system is going to do something equivalent to constructing a “retained mode” GUI on the fly I'm guessing.

[tom_]

It will. In fact, even a simple one will require this. But it's not much of a problem - 99% of the time, the UI is the same from one frame to the next, and it isn't much work to detect this. So even if every change requires a complete rebuild of everything, it's not much of a problem.

(I've written systems like this for Cocoa and Win32, and it never turned out to be necessary to do anything other than just regenerate the entire UI any time anything changed. The update runs at 30Hz or 60Hz, and when anything is changing, the UI gets regenerated a lot! - but so what? Most of the time, the UI doesn't get regenerated at all. Then something happens, and the code spends 2 seconds getting absolutely hammered continuously, malloc malloc malloc malloc malloc, god help us all... and then, once again, nothing. The operator puts their fingers to one side and stares at the result with their eyes. Repeat.)