4 ms·
That's not at all true, at least for Dear ImGui. I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifi
by AussieWog93 5y ago
That's not at all true, at least for Dear ImGui.
I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifically file names with CJK characters), drilling all the way down to individual OpenGL calls to get it running [1].
Apart from any driver-level caches, there really is no UI state.
[1] For what it's worth, this was an easier undertaking than simply recompiling Qt.
- gmueckl 5y agoWhat you're saying is copmpletely wrong. ImGUI is transparently creating structs with internal widget state for every slightly more complex widget on the screen. Look at the state structs in imgui_internal.h to get an idea of what I'm talking about, e.g. ImGuiInputTextState or the huge ImGuiWindow structs. The apparent statelessness of immediate mode GUIs is an illusion that is produced by an extra layer of internal logic that manages that state.
- AussieWog93 5y agoImGuiWindow is an exception to the rule in that it basically serves as a canvas for other widgets to be drawn on. Regarding complex widgets like TextInput or Tables having state, I'm completely OK with that. The problem with state in a retained-mode GUI is that it's stored in two places and can easily fall out of sync/create performance-related footguns/create unnecessary work building widgets. Whether or not they're "pure" immediate mode is not the point.