I’m always interested in the challenging of conventional wisdom. So I consider the 40-minute presentation I just watched on Immediate Mode GUIs to be time well spent.
Essentially: In a situation where your application is going to be constantly updating the screen — ie, a videogame — you can make some serious optimizations from the traditional object-oriented GUI paradigm which make your code a lot more clear. Rather than having event-driven binding, where you’ve got callbacks everywhere to update your model when the GUI state changes, and update your GUI when your model state changes, you draw the widget every frame, with parameters telling the library what should be in it, and get out of that single function call a response with which you can immediately act on.
Instead of Create-Update-Destroy, it’s one call to DoWidget, which may return an interesting value if the user’s done something interesting to it (clicked a button, etc). The logic is simplified immensely. For optimization purposes, you can still do caching on the library side (so you don’t have to rewrap the text in an edit box every frame, for example).
I’ve recently had some excellent results applying coroutines to GUIs (I’ve reached a point where I think hand-coded state machines are almost totally worthless if you have coroutines — unless you want to serialize or look into the state of a task); now I’m curious if I can combine the two ideas.