
Imgui: Immediate Mode Graphical User Interface with minimal dependencies - jblow
https://github.com/ocornut/imgui
======
kevingadd
Other than the REALLY inadvisable name choice (good luck getting precise
search results for the term IMGUI now...), this looks great.

The low # of commits and vague name might be a bad signs, but check the repo
description: Developed at Media Molecule and used internally for a title
they've shipped, with feedback from domain experts like Casey Muratori. Those
two points alone make me pretty excited to try this out.

And a brief explanation of why this matters: IMGUI frameworks are increasingly
popular for editors, debugging tools, etc. because they eliminate the need for
state synchronization between your 'engine' and the visualization/editing UI.
You also avoid the need to duplicate your layout in multiple places - you have
one function that is the complete description of your UI. This reduces memory
usage and can actually be more performant in many cases because you can easily
ensure that you're only ever running code to update visible UI. Things like
virtualized infinite scrolling become quite trivial.

Among other places, IMGUI techniques are used aggressively in Unity's editor.

~~~
seanmcdirmid
Was used in Unity's editor, I don't think that this is the case today.

I believe the project was migrated to github recently, but it has been around
for awhile.

~~~
kevingadd
Still used in Unity for property drawers:

[http://docs.unity3d.com/Manual/editor-
PropertyDrawers.html](http://docs.unity3d.com/Manual/editor-
PropertyDrawers.html)

Not sure how much they use it elsewhere, though. It's possible they phased out
the other uses.

~~~
seanmcdirmid
Hmm...It seems that at least they still are using it:

[http://issuetracker.unity3d.com/product/unity/issues?categor...](http://issuetracker.unity3d.com/product/unity/issues?category=imgui)

I read somewhere that the plan was to migrate away from it, a long time ago
(2/3 years back?), so perhaps they just decided not to.

~~~
DonHopkins
Oh they're definitely migrating away from it, because it was pretty terrible.
Whether it was terrible because it was a bad implementation, or because it was
a bad idea, or because Unity is an editing tool and its users expect a more
"retained mode" approach that enables them to build UIs without writing code,
is an interesting discussion, but Unity is through with immediate mode UIs,
and trying to bury it. Their new stuff is very nice, and leverages many things
about Unity's editor and graphical capabilities, but it's certainly not
minimal.

[http://blogs.unity3d.com/2014/05/28/overview-of-the-new-
ui-s...](http://blogs.unity3d.com/2014/05/28/overview-of-the-new-ui-system/)

~~~
seanmcdirmid
Interesting, thanks for sharing! I think immediate mode done right could be
very liberating, but it requires some more work to get there.

------
w0utert
I was totally sold on this and already preparing to try this out on a simple
game using OpenGL I'm working on as a pet project, until I saw the code
examples. The amount of highly-specific OpenGL code that's apparently needed
to embed an ImgUI popover is completely prohibitive to my use case, the GLEW
and GLFW examples literally have 3 times the number of OpenGL calls my own
rendering function has, I see custom shaders used just for the UI, setting up
clipping rectangles, loading font textures, etc. And that's just to manage
renderer state, not even to setup the popover itself.

I can understand that it's an advantage to have something like this renderer-
agnostic, and embeddable anywhere in your render flow, but the way you have to
use this completely defeats its purpose IMO. I would love a higher-level
abstraction layer on top of this that deals with all the render state setup,
so I only have to setup the UI itself and populate it, and can throw in a one-
liner somewhere in my render function that draws it. In this case, I would
happily trade the fact that this would break render-independence and would
clobber render state, for ease of integration.

That said, the end result looks immensely useful and very-well done, it's just
too involved to setup and use I think...

~~~
ocornut
Hello,

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.

~~~
w0utert
Thanks for the explanation :-)

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.

~~~
ocornut
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.

------
seanmcdirmid
The last time we talked about IMGUI, for historical reference:

[https://news.ycombinator.com/item?id=4201748](https://news.ycombinator.com/item?id=4201748)

------
djoshea
I managed to get this building on MacOS Mavericks using the glew and glfw3
libraries off of homebrew. I forked it at djoshea/imgui

See
[https://github.com/djoshea/imgui/blob/master/examples/opengl...](https://github.com/djoshea/imgui/blob/master/examples/opengl_example/Makefile)

    
    
      brew install glew
      brew install glfw3
      cd examples/opengl_example/
      make
      ./main

------
seanmcdirmid
What is better than using React's one-way reactive dataflow? Well, just run
everything in a continuous loop!

~~~
kevingadd
IMGUI techniques don't even require running a continuous loop... you can use
them in an app that responds to mousemove/mousedown and only paints when
necessary.

~~~
seanmcdirmid
Yep, I've been following this work for awhile now. You can also do much better
than that with incremental execution. See:

[http://research.microsoft.com/apps/pubs/default.aspx?id=1892...](http://research.microsoft.com/apps/pubs/default.aspx?id=189242)

Frameworks like React take a very indirect approach, when it turns out that
the immediate simple approach might be more viable.

For some reason, I'm getting downvotes even though my enthusiasm was genuine.
The mystery of hackernews.

~~~
kevingadd
It totally read like typical HN 'didn't read the article' downvote snark,
especially since it seemed to be comparing it against a javascript MVC
framework. I apologize for downvoting it. :-(

~~~
seanmcdirmid
I guess it sounds so simple that it sounds like snark. I should have been more
detailed, but I decided to throw my two cents in a bit early.

------
Keyframe
This looks sweet, but 6KLoC file. How do you even do that and stay sane?

~~~
blablabla123
I frequently see such long files when looking at typical C or C++ projects,
actually both closed and open source. Most other languages seem to have
unwritten laws that source files shouldn't be larger than 500 LOCs.

~~~
to3m
Provided you avoid globals, the sky's the limit. My professional record is
17,000 lines; after a while it became a game, to see how far we could take it
before somebody cracked. But in the end the project finished before anybody
felt the need to split it up. It was actually very easy to keep on top of and
handy to have everything in one place.

You do need some better way of navigating round the file than search, though!
I recommend something like visual assist or imenu.

~~~
blablabla123
Haha, sounds like fun

------
arianvanp
This is why I like FRP. It is like the perfect combination of imguis and
normal guis. Just treat all events as time varying values and you're basically
just writing imgui code.

------
remon
Well, if there is an award for the library name that is hardest to get Google
results for this one is a contender.

~~~
dTal
People keep saying that in this thread but I don't see why. It's a unique
enough name, and the entire first page of results is relevant. What's so bad?

~~~
jsnell
It's like naming your new Model-View-Controller library simply "MVC". Ok if
you're the one who first came up with MVC, less so if it's already a well-
established term. Yes, all the results in that first page of results is
relevant. But the results aren't relevant because they're referring to this
library. Instead the library is co-opting the term that all of those search
results are referring to.

------
rsync
Is there an equivalent tool for ncurses ?

Just curious ...

~~~
clarry
Or just for ANSI-capable terminals, without involving any cursing and
terminfo/termcrap nightmares.

~~~
gcb0
what you ask is impossible. unless you do:

1\. get the screen height 2\. draw a block with ascii art with that height.
3\. when done put height*line breaks to clean the screen.

or do you want something to handle termcap for you? `dialog` i think does that

~~~
clarry
I said ANSI-capable. I also assumed the terminal dimensions are either fixed
or can be retrieved somehow, e.g. from the environment or via an ioctl like in
Unixy systems.

So TIOCGWINSZ for the dimensions. And printf("\033[7m") to get a background
for the box (you can use colors too, though I think they're mostly fugly).
printf("\033[2J") to clean the screen.

[https://en.wikipedia.org/wiki/ANSI_escape_sequence](https://en.wikipedia.org/wiki/ANSI_escape_sequence)

Using an API wrapping the database of terminal incompatibility might've been a
good idea in the days of hardwired glass terminals. But nowadays it can cause
more problems than it solves, plus it's ugly as hell. Also, we now have
standards and emulators to rely on for when you can't otherwise adapt.

Try get to your shell on an older Solaris box connecting via rxvt-unicode. Oh,
missing a terminfo entry? That's _easy_ (if you know how to add it, as a
user). But, wait, the name of the terminal is too long! So all applications
which rely on curses or term(info|crap) will give you grief. Even though all
terminals (terminal emulators really) people use these days support a
reasonable subset of the ANSI escape codes -- and when they don't, you can run
something like GNU screen between your terminal and the application. _Things
would just work if applications assumed a standard and didn 't rely on a huge
database and thousands of lines of code to deal with it._

------
3rd3
(How) does this compare to AntTweakBar?

------
huhtenberg
Not to state the obvious, but there are very few types of desktop programs
where _not_ having a native look and feel is OK. Especially when UI looks as
unique as ImgUI does. Games, demos and, perhaps larger application software,
like Blender, that are meant for prolonged continuous use and that run full-
screen.

ImgUI is a very nice engineering feat, but it's not terribly practical.

~~~
Karunamon
It's sold and presented as an engineering tool. Why does something simple that
only the developers are supposed to see need UI chrome bloat on top of it?

> _ImGui is designed to allow programmers to create "content creation" or
> "debug" tools (as opposed to tools for the average end-user). It favors
> simplicity and thus lacks certain features normally found in more high-level
> libraries, such as string localisation._

