I don’t buy it. The creator of Dear IMGUI himself says it’s slower. These posts never talk about how their compositor (if they’re even using one) maintains perf

I don’t buy it. The creator of Dear IMGUI himself says it’s slower. These posts never talk about how their compositor (if they’re even using one) maintains performance. Are you building vertex buffers? Are you creating backing layers? These are the critical details, not whether or not the API itself “looks” like an immediate mode or retained mode API. Even the immediate mode APIs retain information! As soon as you do compositor work, you need framebuffers, and you can kiss perf goodbye as you realize you can’t just destroy panels left and right without some abstraction to efficiently use video memory. Oh, you can’t paint then scale later? Oh, so to do transparency effects you have to redraw the primitives every frame with new alphas instead of sending a different alpha to your shader? OK. Sure. What’s your invalidation strategy? You don’t have one because it’s all “immediate,” sure. That’s really interesting. If there’s no performance difference, then well, hmm, why didn’t we do this back in the win32 era? Oh well, of course, it’s because there is a performance difference. And it’s staggering. The most critically important work I’ve seen in modern GUI architecture has nothing to do with the API itself and everything to do with the compositor. You can make the API almost always look like anything you want. Under the hood, it’s frametime life or death depending on how you rasterize and display large amounts of UI and typesetting, and panel layout.