But their design just seems broken, if they're re-initializing the graphics context on every runloop iteration?
So what Emacs does is keep control of its own main loop. It has a select() that listens for events, and then calls NSApplication:run in the event handler. Emacs’s implementation of run() processes all pending events and then exits and returns control to the real Emacs main loop. So every keystroke or timer event in Emacs invokes setting up and tearing down the entire NSApplication main loop.
The relevant code is ns_select_1 in nsterm.m, line 5102. https://github.com/emacs-mirror/emacs/blob/master/src/nsterm...
The model of "slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event" is precisely what [NSApplication run] already implements. Per Apple
>A Cocoa application is event driven: It fetches an event from the queue, dispatches it to an appropriate object, and, after the event is handled, fetches the next event. With some exceptions (such as modal event loops) an application continues in this pattern until the user quits it.
But what it is doing is first posting a message that will call `[NSApp stop]` then calling `[NSApp run]`. Which is odd, because `[NSApp nextEvent]` exists, but even if that doesn't work it's not the way I'd do it. However I'm sure there are very good reasons to do it this way when you know the emacs source.