IMGUI does is NOT inefficient, since it does not do immediate mode rendering. From IMGUI Github's: "A common misunderstanding is to mistake immediate mode gui for immediate mode rendering, which usually implies hammering your driver/GPU with a bunch of inefficient draw calls and state changes as the gui functions are called. This is NOT what Dear ImGui does. Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely."
@1:10 it really does not regenerate the entire GUi it store a lot (and i mean a lot) of state internally. So technically the library emulates immediate mode.
that's the imgui performance secret sauce. immediate mode interface, retained mode implementation. Some imgui implementations make that more explicit, where you actually have to manually mark widgets as "dirty" and etc.
@@nlguillemot would probably not have been a bad idea to mention that in the presentation. To not have performance-freaks immediately leave the room ;)
@@TheLeontheking Indeed. I was about to leave the room until I checked the lib my self. Drawing every single widget every is nuts even for just prototyping.
@luk3dcode its open source. If you want to learn how it works, you are expected to go inspect it yourself. Makes sense though right? There aren't youtube tutorials for everything in the world.
@@ancientapparition1638 I agree with him about writing your own if you aren't strapped for time, I used Dear imGui (or rather, the C# fork of it) when I was building the game engine that my team never ended up using (but I'm still updating it slowly for future) and it got messy because I didn't really know exactly what it was doing behind the scenes. Slowly but surely started converting the tools to our own library and it's so much cleaner.
@@FPSAnarchy This actually sounds like a point for imgui, not against. If you've spent 1 month understanding imgui instead of 7 months writing your own, you might have gotten your job done faster.
@@szaszm_ can you recommend me where to learn abt imgui, like it does not have even proper docs :( I m very curious to learn it. The tuts I see just start by copy pasting the code from imgui examples and not explaining even single like.
Many many misconceptions. Immediate mode GUIs do not inherently poll; they can react to events and only redraw when necessary. This point frustrates me especially because """performance""" is held on a golden pedestal and has stopped many people from using immediate mode GUIs. While the code may appear to always rebuild the UI, lots of state is cached, up to the extreme of storing an entire retained mode GUI inside of the immediate mode library and diffing it (in reality most real-world libraries are somewhere in the middle and cache some layouts, eg for top-level windows and panels). Also he says widget wrong.
It's funny that "performance" is the problem called out about ImGUI, and not when excessive object hierarchies cause UI to run like a turtle in molasses.
The GPU is always being called regardless what's happening. Just don't draw white forever. There are always going to be misconceptions like multithreading and pointers.
The problem I see with Imgui is that the frametime gets doubled. So I am gonna use it temporarily while the program is in development, but good video tho
I think it's a little fucked up that I googled "immediate mode gui vs retained" and the 2nd response is probably the best and most concise answer to my question, answered by one of my best friends. How am I this blessed.
Hi. I was wondering if there's any convenient way of integrating ImGUI with SDL2. I know about demos on ImGUI github page but it seems that such approach cancels out ability to you SDL's SDL_Renderer objects.
I know about these samples/examples but as I said I want to know how to preserve SDL_Renderer functionality. Because currently in these examples it just won't work as expected after ImGUI::render() call.
