Don't throw it all away: Caching an immediate-mode UI

Immediate-mode user interfaces (UIs) are often criticized for repeatedly rebuilding the interface description each frame, even if little has changed. However, this tradeoff may not be as detrimental as it seems. Modern computers are fast enough that rebuilding the UI takes very little time, often less than a millisecond. If the user does not mind the repeated work, a simple solution is to put the application to sleep when no user interaction is happening. This approach is already implemented in many immediate-mode desktop apps and is often sufficient.

Another consideration is power usage, especially on laptops, phones, and tablets. High-resolution displays with high refresh rates exacerbate this issue, especially when the application displays a blinking cursor, moving playhead, or animated control, preventing the application from sleeping and constantly updating the interface.

To address this, a caching system can be attached to the rendering side of the UI system. The UI can rebuild the entire interface description each frame while the renderer retains the pixels it has already produced and repaints only the parts whose rendering inputs changed. This way, the UI and renderer can coexist, with the UI describing the interface and the renderer remembering its previous output.

In practice, the renderer can split the window into tiles and compare command hashes with the previous frame to determine which tiles need repainting. By doing this in the renderer, the UI system does not need to maintain a separate list of changed widgets, as the change can be determined from the drawing commands. This approach allows for efficient redraws, as it avoids unnecessary work and leverages GPU processing.