Game Development Reference
2.1R ETAINED M ODE
A retained mode user interface is one in which the components of the UI system are objects
capable of retaining a state. What this means is that an element of the UI can be created as
an object, kept around for as long as it's necessary and eventually released when no longer
Let's dissect a simple UI element to see what makes it a retained.
std::shared_ptr<Label> exampleLabel = UI.CreateLabel(“Example Label”);
Here, exampleLabel will exist until it no more shared pointers to it exist, it also will have an
internal string member in which it keeps the text for the label “Example Label”, this means
that each label has a memory cost. If we track the amount of memory used by each active
UI element, we can calculate the memory cost of the entire UI at any given moment.
Retained mode UIs are common in games because they're intuitive to develop in terms of
object oriented design and lend themselves well for the creation of UI authoring tools, but
more importantly, game designs vary greatly and we need the ability to create completely
customized behaviors that go beyond simple user interface components such as labels and
simple buttons, the ability to create custom elements is crucial.
There can be substantial overhead in terms of code management using a retained mode sys-
on the users to understand the model, in particular the lifetime and ownership of the objects.
Modern UIs continue to become complex and reactive and for this it has become important
to multithread portions of UI code, a retained mode system lends itself well for multith-
reading as we can cache and prepare data, tick animations and process the frame during the
game's update thread then the render thread may capture a snapshot of the user interface
data at the moment when it's ready to display it.
For our purposes, a callback is a function that we provide to a system with the expectation