I was interested and wanted to see how much the animations burn CPU and whatnot, so I cloned the repo and went to try to build the demo but everything went to hell. The build environment is some .net thing written in C#. It comes with a "bootstrap.sh" file to get it going that immediately fails, even after installing the dotnet development environment. I fiddled around with it for some time before giving up because I was hitting an error about a Targeting Pack that was going to require me to hit a Microsoft website to fix.
But the README says the build process it just a couple of files so I figured I could just build it by hand. This involved downloading a couple more repos from the author's repo and setting up some symlinks, includes, and defines that I figured out through trial and error, but in the end I was not successful in getting the demo to build. I tried a combo of SDL2 and OpenGL3 but it bombed out with a C++ error about too many initalizers. The only good news is that I was able to cleanly build the demo_im_app code, but the main requires the ImPlatform which appears to be buggy.
Update: I figured out that you need to run a git submodule update command first. The shell script is supposed to tell you this but it is broken. This does a bunch of work but then dies because g++ doesn't stick the string ".exe" on the end of executibles. Also, the script looks in the wrong place for the output. A few text fixes in the bootstrap.sh and generate_projects.sh files and it gets to a point where the build is dying due to not having "main" or "sharpmake" objects in the current context, whatever that means. I don't know enough about C# to go further, especially for what was supposed to be a quickie 10 minute test. I'm hoping someone else figures this out and updates the repo.
You should be run bootstrap and generate_project script.
For ImPlatform I didn't have setup to tests all permutations. For ImPlatform you should try glfw-opengl3 or Win32-dx11 for windows.
bootstrap.sh is buggy. The message about running the git submodule command is never shown because the directory already exists in the repo.
It also looks specifically for .exe files, when a linux compiler won't append that suffix.
It also looks in the x64 directory, which was not created when I ran it.
For some reason even though I have dotnet 8.x installed it compiled with dotnet 6.x and complained about 6.x being obsolete.
The generate_project script also looks for a .exe file, but even when stripped off the process fails with namespace errors for 'main' and 'sharpmake'. These errors occur in a temporary file unfortunately so they're hard to investigate.
Otherwise if you are already a Dear ImGui user:
https://news.ycombinator.com/item?id=46111925
Just add 2 files im_anim.h/cpp in your project and you're done! And if you want the demo add demo_im_anim.cpp and call ImAnimDemoWindow(). Don't over complicate things.
For perf usage the demo for 100+ of anims (clip, tween, stagger, ...) it cost between 2-5 ms depending on your computer (that's not mean a proper benchmarks).
ImGui is great if you need an ad-hoc UI for development/debug tools, but it's not meant to be used in actual applications aimed at end-users. I can't speak for other devs but I certainly wouldn't want my development tools waste time with pointless animations. I hope this doesn't encourage even more devs to build inaccessible software featuring ImGui's idiosyncratic, non-standard UX.
I agree with your points about ImGui's intended use case, though I think the landscape is a bit more nuanced. You're right that ImGui excels for dev tools and that its non-standard UX isn't ideal for end-user apps. That said, devs reach for ImGui in end-user apps because lightweight cross-platform alternatives are scarce. Qt is heavy, Electron is heavier, native toolkits mean multiple codebases.
I built a techy tool with ImGui (JSONL Viewer Pro) and it works well enough for users who care more about functionality than polish. Not saying it's right for consumer apps, but for technical tools it can be pragmatic.
I've thoroughly enjoyed using ImGui for tooling around image processing, computational geometry, a bunch of 3D projection stuff. The fact that it's based on OpenGL or Vulkan or whatever backend you want is a big win for this kind of work. I can just take a bunch of pixels, throw them into a texture, and render some quads with those textures painted on them after going through some 2D transformations or 3D projection/transformation. It's quite beautiful for all of this. ImPlot for doing basic data plotting and the built-in ImGui widgets for controlling the whole thing.
Exactly, I was working on a little client for a self-hosted server app. Imgui is a rare mix of fast, lightweight, trivially cross-platform and stable, so I went with it and had the client easily compiling for Windows, Linux and browser, while being trivial to work with.
I have otherwise mostly given up on making GUI applications because I simply don't have time to pick up a bunch of UI toolkits for all the different platforms, pulling a massive dependency into my project and requiring constant maintenance to keep the program working.
It also have bindings for a ton of languages, so for people who jump languages a lot, it's always nice to be able to reach for something more familiar that you can learn across different codebases but same concepts. Same thing for the backend/engine, UI code remains the same, but easy to switch to others or even wrapping it yourself for platforms that are under NDA.
I know that at least one modding framework for a certain online game makes use of ImGui (or some equivalent thereof). Given the use case it does make a lot of sense, considering they're essentially strapping a third party UI onto an existing 3D accelerated application, not sure what else you'd use for that. Since the users are technical enough to install the mod framework anyways, they tend to be the sort that can handle the UI.
It can be a bit wonky though, I regularly spot UI/UX decisions that seem to map more closely to what the developer is doing under the hood, or their own mental model of the problem, than what one might consider to be an intuitive way of interacting with the system.
IME, it's great for building full standalone applications. I've used it to build several internal tools for non-engineers. A tool like that doesn't need to work with a screen reader, or have native buttons, etc. It needs to be easy to build and iterate on.
This isn't to say a tool for non-engineers should have animations to make it useful. ImAnim should probably be used sparingly, if at all.
If you need the features of a full GUI toolkit, then by all means use Qt or wxWidgets etc, but that's a very big jump in project complexity.
For applications where the aim is high sales volume and low support, you're absolutely right.
But "development/debug tools" is actually just a subset of professional or industrial utility applications where user count is low and support is on the extremes (either "capable self-support" or "Yes, Bob, of course we'll add that for you").
And in those utility applications, you probably don't need the noisy toy animations associated with modern consumer software, but animated data representations can be really valuable.
imgui success is a silent protest from tons of C++ developers, fed up with the over-engineering and enterprise-ification of everything in this bloated ecosystem.
>I certainly wouldn't want my development tools waste time with pointless animations.
On one hand I agree. On the other: where are these high performance real-time GUI kits these days? If it came down to IMGUI or shoving Electron into my app...
I somewhat mirror this opinion, but I would like to point out that there are scant alternatives that meet the intersection of attributes ImGui possesses. The best alternative I've seen as of late is Slint[1]. It's early days but it's looking very promising and is light enough to work on embedded systems.
ImGui is just very weird. For the intended use case it is quite good, but for more general applications it is just not a good UI library.
It is popular mostly because all alternatives are really bad, if "all" you want is a functional GUI to deliver some developer tool. Qt means you have to dive really deep into a C++ project. The web technologies are all far too heavy and complex and you don't really any of the power. There also are many other alternatives, none of them really do what ImGui does.
I depends on the field. On VFX/Game world, Dear ImGui seem to be the way to go. Almost all news comer in this field sells Dear ImGui based software. It's fast and light and trivially profilable that's what matter matter for real time applications. And bonus can be integrated in any platform in few hour of devs. Before having any ui in VR or game console (not necessary debug/dev tool) in Qt or anything else it will take ages.
I’m still waiting for the day for someone to get a clue and build a pro or prosumer level LLM front end with Imgui. It’s the perfect use case for imgui to have a “blender” type product.
Author (me):
I updated the repo for being much simpler for new user.
Like Dear ImGui, open ./examples/ and if you are in windows/Visual Studio just open:
ImAnim_vs2022_Win64.sln
And chose between win32_dx11, glfw3_opengl3 or sdl2_opengl3
You have *.bat or Makefile in each folder:
glfw_opengl3
sdl2_opengl3
win32_directx11
If the author is around, can you do a short writeup on how this implemented? I've got my own immediate-mode UI framework and am curious how you did it.
The author here.
You have various concepts but overall we store the start time and that's it :D the rest are details, clip, tween, easing function, anchor have surviving resizing, stagger to generate the same anim with variations. Or variations of clips, loop.
Proper anim of colors in oklab, oklch, linear srgb, hsl, ...
Anyway I cannot explain much it's really simple code with a userfriendly front-end.
tl;dr It's not an implicit animation framework like Core Animation or CSS animations. Instead, each frame you get the current value which is then used, and the actual tween curve only changes when you call a tween function with a new target; otherwise, you get the current (tweened) value since the last time the target changed (which might be the final value).
If Claude can implement my todo list:
* Lazy eval (cost only at the first run)
* Animation clipping (evaluate only the visible one)
I'll accept the PR.
I was interested and wanted to see how much the animations burn CPU and whatnot, so I cloned the repo and went to try to build the demo but everything went to hell. The build environment is some .net thing written in C#. It comes with a "bootstrap.sh" file to get it going that immediately fails, even after installing the dotnet development environment. I fiddled around with it for some time before giving up because I was hitting an error about a Targeting Pack that was going to require me to hit a Microsoft website to fix.
But the README says the build process it just a couple of files so I figured I could just build it by hand. This involved downloading a couple more repos from the author's repo and setting up some symlinks, includes, and defines that I figured out through trial and error, but in the end I was not successful in getting the demo to build. I tried a combo of SDL2 and OpenGL3 but it bombed out with a C++ error about too many initalizers. The only good news is that I was able to cleanly build the demo_im_app code, but the main requires the ImPlatform which appears to be buggy.
Update: I figured out that you need to run a git submodule update command first. The shell script is supposed to tell you this but it is broken. This does a bunch of work but then dies because g++ doesn't stick the string ".exe" on the end of executibles. Also, the script looks in the wrong place for the output. A few text fixes in the bootstrap.sh and generate_projects.sh files and it gets to a point where the build is dying due to not having "main" or "sharpmake" objects in the current context, whatever that means. I don't know enough about C# to go further, especially for what was supposed to be a quickie 10 minute test. I'm hoping someone else figures this out and updates the repo.
You should be run bootstrap and generate_project script. For ImPlatform I didn't have setup to tests all permutations. For ImPlatform you should try glfw-opengl3 or Win32-dx11 for windows.
bootstrap.sh is buggy. The message about running the git submodule command is never shown because the directory already exists in the repo.
It also looks specifically for .exe files, when a linux compiler won't append that suffix.
It also looks in the x64 directory, which was not created when I ran it.
For some reason even though I have dotnet 8.x installed it compiled with dotnet 6.x and complained about 6.x being obsolete.
The generate_project script also looks for a .exe file, but even when stripped off the process fails with namespace errors for 'main' and 'sharpmake'. These errors occur in a temporary file unfortunately so they're hard to investigate.
Otherwise if you are already a Dear ImGui user: https://news.ycombinator.com/item?id=46111925 Just add 2 files im_anim.h/cpp in your project and you're done! And if you want the demo add demo_im_anim.cpp and call ImAnimDemoWindow(). Don't over complicate things.
I added simple_example for you, should now with zero setup.
For perf usage the demo for 100+ of anims (clip, tween, stagger, ...) it cost between 2-5 ms depending on your computer (that's not mean a proper benchmarks).
ImGui is great if you need an ad-hoc UI for development/debug tools, but it's not meant to be used in actual applications aimed at end-users. I can't speak for other devs but I certainly wouldn't want my development tools waste time with pointless animations. I hope this doesn't encourage even more devs to build inaccessible software featuring ImGui's idiosyncratic, non-standard UX.
I agree with your points about ImGui's intended use case, though I think the landscape is a bit more nuanced. You're right that ImGui excels for dev tools and that its non-standard UX isn't ideal for end-user apps. That said, devs reach for ImGui in end-user apps because lightweight cross-platform alternatives are scarce. Qt is heavy, Electron is heavier, native toolkits mean multiple codebases. I built a techy tool with ImGui (JSONL Viewer Pro) and it works well enough for users who care more about functionality than polish. Not saying it's right for consumer apps, but for technical tools it can be pragmatic.
> but for technical tools it can be pragmatic
I've thoroughly enjoyed using ImGui for tooling around image processing, computational geometry, a bunch of 3D projection stuff. The fact that it's based on OpenGL or Vulkan or whatever backend you want is a big win for this kind of work. I can just take a bunch of pixels, throw them into a texture, and render some quads with those textures painted on them after going through some 2D transformations or 3D projection/transformation. It's quite beautiful for all of this. ImPlot for doing basic data plotting and the built-in ImGui widgets for controlling the whole thing.
Exactly, I was working on a little client for a self-hosted server app. Imgui is a rare mix of fast, lightweight, trivially cross-platform and stable, so I went with it and had the client easily compiling for Windows, Linux and browser, while being trivial to work with.
I have otherwise mostly given up on making GUI applications because I simply don't have time to pick up a bunch of UI toolkits for all the different platforms, pulling a massive dependency into my project and requiring constant maintenance to keep the program working.
It also have bindings for a ton of languages, so for people who jump languages a lot, it's always nice to be able to reach for something more familiar that you can learn across different codebases but same concepts. Same thing for the backend/engine, UI code remains the same, but easy to switch to others or even wrapping it yourself for platforms that are under NDA.
I know that at least one modding framework for a certain online game makes use of ImGui (or some equivalent thereof). Given the use case it does make a lot of sense, considering they're essentially strapping a third party UI onto an existing 3D accelerated application, not sure what else you'd use for that. Since the users are technical enough to install the mod framework anyways, they tend to be the sort that can handle the UI.
It can be a bit wonky though, I regularly spot UI/UX decisions that seem to map more closely to what the developer is doing under the hood, or their own mental model of the problem, than what one might consider to be an intuitive way of interacting with the system.
IME, it's great for building full standalone applications. I've used it to build several internal tools for non-engineers. A tool like that doesn't need to work with a screen reader, or have native buttons, etc. It needs to be easy to build and iterate on.
This isn't to say a tool for non-engineers should have animations to make it useful. ImAnim should probably be used sparingly, if at all.
If you need the features of a full GUI toolkit, then by all means use Qt or wxWidgets etc, but that's a very big jump in project complexity.
For applications where the aim is high sales volume and low support, you're absolutely right.
But "development/debug tools" is actually just a subset of professional or industrial utility applications where user count is low and support is on the extremes (either "capable self-support" or "Yes, Bob, of course we'll add that for you").
And in those utility applications, you probably don't need the noisy toy animations associated with modern consumer software, but animated data representations can be really valuable.
imgui success is a silent protest from tons of C++ developers, fed up with the over-engineering and enterprise-ification of everything in this bloated ecosystem.
“and that’s a bad thing!”
>I certainly wouldn't want my development tools waste time with pointless animations.
On one hand I agree. On the other: where are these high performance real-time GUI kits these days? If it came down to IMGUI or shoving Electron into my app...
I somewhat mirror this opinion, but I would like to point out that there are scant alternatives that meet the intersection of attributes ImGui possesses. The best alternative I've seen as of late is Slint[1]. It's early days but it's looking very promising and is light enough to work on embedded systems.
[1] https://slint.dev/
ImGui is just very weird. For the intended use case it is quite good, but for more general applications it is just not a good UI library.
It is popular mostly because all alternatives are really bad, if "all" you want is a functional GUI to deliver some developer tool. Qt means you have to dive really deep into a C++ project. The web technologies are all far too heavy and complex and you don't really any of the power. There also are many other alternatives, none of them really do what ImGui does.
I depends on the field. On VFX/Game world, Dear ImGui seem to be the way to go. Almost all news comer in this field sells Dear ImGui based software. It's fast and light and trivially profilable that's what matter matter for real time applications. And bonus can be integrated in any platform in few hour of devs. Before having any ui in VR or game console (not necessary debug/dev tool) in Qt or anything else it will take ages.
I’m still waiting for the day for someone to get a clue and build a pro or prosumer level LLM front end with Imgui. It’s the perfect use case for imgui to have a “blender” type product.
Bliss:
Exactly! And add the demo file to see it in action.
Author (me): I updated the repo for being much simpler for new user. Like Dear ImGui, open ./examples/ and if you are in windows/Visual Studio just open: ImAnim_vs2022_Win64.sln And chose between win32_dx11, glfw3_opengl3 or sdl2_opengl3 You have *.bat or Makefile in each folder: glfw_opengl3 sdl2_opengl3 win32_directx11
Enjoy/
If the author is around, can you do a short writeup on how this implemented? I've got my own immediate-mode UI framework and am curious how you did it.
The author here. You have various concepts but overall we store the start time and that's it :D the rest are details, clip, tween, easing function, anchor have surviving resizing, stagger to generate the same anim with variations. Or variations of clips, loop. Proper anim of colors in oklab, oklch, linear srgb, hsl, ... Anyway I cannot explain much it's really simple code with a userfriendly front-end.
Thanks, I had Claude walk me through the code if anyone is curious:
https://claude.ai/share/12357895-d585-4475-93fb-cdb5eba5dd76
tl;dr It's not an implicit animation framework like Core Animation or CSS animations. Instead, each frame you get the current value which is then used, and the actual tween curve only changes when you call a tween function with a new target; otherwise, you get the current (tweened) value since the last time the target changed (which might be the final value).
If Claude can implement my todo list: * Lazy eval (cost only at the first run) * Animation clipping (evaluate only the visible one) I'll accept the PR.
Not the author but it‘s implemented in only two files which can be studied on Github.
oh wow this timing is incredible for me thank you, this is exactly the type of thing I needed and this is EXACTLY my aesthetic