The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily.
Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case).
It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that.
This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler.
A stripped-down minimal example would be very helpful to show how to use the library, just a simple popover with a single control and the absolute minimum required render calls for example. I agree that the fact that this is render-agnostic by the way, and like you mentioned yourself: if you need this you probably have most of the initialisation and shader compilation stuff covered, I wrote some simple wrapper classes for ES2 myself. But a really thin OpenGL (ES) or DirectX specific layer on top of the core functionality would also be great to make the tool a little more accessible of course ;-)
Great work nonetheless, maybe I'll play around with it anyway to see how much work it actually is to embed this in my (at this stage extremely bare-bones) renderer.
The thing with how rendering work is that a "complex UI" vs a "single control" will use the same and only rendering feature required, aka: "render triangle list given a scissoring rectangle". There's no middle ground.
I will provide an example app that use glScissor() and the fixed pipeline so no custom shaders will be required. However I am not sure how the performance will behave with widgets that frequently change the clipping rectangle. At the moment the system is optimised to minimize draw calls (I would like a typical "complex" tool to take under 0.5/1.0 milliseconds to build and render). I was actually considering moving the clipping rectangle within the vertex buffer so everything could be rendered in 1 draw call, which would simplify the code and be faster, but requires a custom shader. That is to say, it is an open ended problem and there's not one single solution.
I already pushed some tweaks and comments in the sample applications. Your criticism is perfectly legit and I aiming to simplify integration as much as possible so please don't hesitate to comment further if you had another go at it.
Thanks for your feedback (I am the author).
The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily.
Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case).
It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that.
This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler.
Best. O.