ImAnim brings tweens, clips and noise to Dear ImGui in two files and two calls

Integration is two copied files and two calls per frame

ImAnim is an animation engine for Dear ImGui, and its pitch is deliberately narrow: no build system changes and no external dependencies, since only Dear ImGui is required. Integration is a copy operation. You take im_anim.h and im_anim.cpp into your project, add two lines after ImGui::NewFrame(), and start calling the API.

The one-line entry point is the tween helper, which takes an id, a channel, a target value, a duration, an easing, a policy and the frame delta.

// Animate anything in one line
float alpha = iam_tween_float(id, channel, hovered ? 1.0f : 0.5f, 0.3f, ease, policy, dt);

That signature carries the whole design in one line. A tween is identified by an id and a channel, it moves toward a target, and the policy decides what happens when a new value arrives while the old one is still running. Because the id and channel are explicit, the same logical element can be animated from different places in your draw code without a global registry.

The repository is a plain source tree rather than a package: the top level holds im_anim.h, im_anim.cpp, im_anim_demo.cpp, im_anim_doc.cpp and im_anim_usecase.cpp, plus CMakeLists.txt and a LICENSE file. There is no build artifact in the listing, so copying the two files is the intended path.

The frame hook is where animation state actually advances

Immediate-mode UI has no retained widget objects, so an animation engine built for it has to keep its own state and decide when to advance it. ImAnim does that with two calls placed right after ImGui::NewFrame().

ImGui::NewFrame();

// Add these two lines
iam_update_begin_frame();
iam_clip_update(ImGui::GetIO().DeltaTime);

// Your UI code...

iam_update_begin_frame() opens the engine's update for the frame, and iam_clip_update() advances timeline clips using the delta time reported by ImGui. The ordering matters more than it looks. The hook runs before your UI code, so a value read in your draw code reflects the current frame rather than the previous one, which is what stops a hover fade from lagging a frame behind the cursor.

The same dt also flows through individual tweens. The hover example the README gives passes ImGui::GetIO().DeltaTime as the last argument of iam_tween_float, so the tween is time-based rather than frame-based and stays consistent when the frame rate changes.

For a reader wiring this up for the first time, the practical detail is that the two calls must sit in one place in your frame loop. Scattering them across the draw code, or calling them conditionally, breaks the sequencing the engine assumes.

Tweens key on widget id plus channel, and each target type has its own policy

The feature table lists tweens for float, Vec2, Vec4, int and color, and pairs them with crossfade, cut and queue policies. Those three policies answer the question every tweening library has to settle: what happens when the target changes while an animation is still running.

The hover example shows how the keys are chosen.

bool hovered = ImGui::IsItemHovered();
float scale = iam_tween_float(
    ImGui::GetID("btn"), ImHashStr("scale"),
    hovered ? 1.1f : 1.0f, 0.2f,
    iam_ease_preset(iam_ease_out_back),
    iam_policy_crossfade,
    ImGui::GetIO().DeltaTime
);

The first key is ImGui::GetID("btn"), the widget id, and the second is ImHashStr("scale"), the channel. Using the widget id means the state follows the element even if it is drawn from a helper function, and using a named channel lets several independent properties of the same element animate at once, since scale and alpha would be different channels under the same id.

The easing comes from iam_ease_preset with iam_ease_out_back, which is one of the presets the README counts in a collection of more than thirty easing functions including spring physics. The duration is 0.2 seconds, and iam_policy_crossfade decides what a target change does mid-flight.

The README also lists resolved tweens under advanced features, which is the mechanism for computing a target dynamically instead of handing over a finished value.

Clips add timelines where a one-shot tween stops working

Tweens answer a single question: how do I get from the current value to the next one. ImAnim adds a second layer for sequences. Clips are described as timeline keyframes with looping, callbacks, chaining, stagger and variations, and the engine has a dedicated per-frame update for them, which is what iam_clip_update in the frame hook drives.

The pieces cover different needs. Chaining is for one clip after another, callbacks for reacting to a moment inside a timeline, and stagger for cascading a list of elements so they arrive one after another instead of all at once. Variations change parameters per loop, which is how a repeated animation can avoid looking identical on every pass. The docs list includes separate pages for stagger, text stagger, layering and resolved tweens, so each of these is treated as its own mechanism rather than a flag.

Two supporting systems matter for real interfaces. Anchors provide animation that is relative to an element's position, described in the README as anchor-relative animations that survive window resizing. Layering blends multiple animations at once, which is what lets a hover effect and a press effect overlap without either owning the value outright.

For an application with a lot of similar widgets, the stagger and anchor pages are the ones worth reading first, because they change how the surrounding draw code is written.

Paths, noise and OKLAB colors sit above the tween layer

Beyond timed transitions, ImAnim includes a set of generators that produce values continuously. Paths cover Bezier curves, Catmull-Rom splines, path morphing between curves and text along paths, which is curved text rendering. Oscillators produce continuous periodic motion, shake and wiggle give feedback-style movement, and Perlin and Simplex noise provide procedural animation for values with no natural start and end.

Colors have their own treatment. The README names perceptual color blending in OKLAB and OKLCH space, plus gradients and style interpolation, and the latter is aimed at theme transitions rather than single widgets, interpolating an ImGui style over time.

Per-axis easing appears in the documentation list as its own topic, allowing different easing per component, which matters when scaling a Vec2 where a uniform curve would look wrong on one axis.

Tools round this out: a debug inspector, a profiler, save and load, and memory management. The debug helper screenshots in the README show a timeline view for clips and support for delayed start. Since the engine keeps per-element state keyed by ids and channels, an inspector is the practical way to see what that state actually holds at runtime rather than guessing at it.

Building the demo means picking a backend permutation first

The examples folder holds a Visual Studio solution, per-backend Makefiles for Linux and macOS, an ImPlatform abstraction, and a CMake path that the README says is what CI runs.

On Linux and macOS each backend has its own Makefile.

cd examples/glfw_opengl3
make

# or
cd examples/sdl2_opengl3
make

The CMake path compiles the demo against every backend permutation ImPlatform supports and builds ImPlatform from the submodule, so no system Dear ImGui is needed.

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target ImAnimDemo_GLFW_Vulkan --parallel

Binaries land in build/bin/. The README explains that configurations whose dependencies are missing are skipped at configure time with a message, so a partial toolchain still builds what it can. That is a deliberate convenience for someone trying the engine on a machine with only part of a graphics stack installed.

The backend table explains why some rows are empty. GLFW is deliberately absent from the DirectX rows because it exposes no native window handle, so the DirectX backends cannot obtain an HWND from it. Vulkan on macOS runs through MoltenVK. On Windows the solution file offers Release_Win32_DX11, Release_GLFW_OpenGL3, Release_SDL2_OpenGL3 and Release_ImPlatform configurations, with debug variants of each.

The Metal backends compile but do not run

The most useful thing in the README is also the most negative. The Metal configurations currently compile but do not run, because ImPlatform_InitGfxAPI in ImPlatform's Metal backend still returns false pending an NSWindow accessor on the GLFW and SDL3 backends.

That is a specific, bounded failure rather than a vague warning. On macOS, the table shows GLFW_Metal and SDL3_Metal marked for macOS only, and both are affected. The GLFW_Vulkan and SDL3_Vulkan rows do cover macOS and go through MoltenVK, so there is a working macOS path in the matrix, just not a Metal one. The GLFW_OpenGL3 row covers Linux and macOS as well.

Two caveats come with the same matrix. The SDL3_OpenGL3 row lists Linux but not macOS, and SDL3_DX11 is a Windows-only combination, so the SDL3 backend has different coverage per graphics API. And the absence of GLFW from the DirectX rows is a design constraint of GLFW rather than a bug in ImAnim.

For anyone planning a macOS release, this determines which demo configuration to validate against, and it also means the ImPlatform dependency has to be tracked separately since it arrives through a submodule.

Version 1.0.0 is the first official release, under MIT

The repository lists 1.0.0 as the first official release, described as a stable release with a complete animation toolkit for Dear ImGui, and the version badge in the README matches that number. The 1.0.0 release is dated 2025-12-12, while the last push to the repository was on 2026-10-15, so the source tree has moved on from that tag without a newer tagged release.

The license is MIT. The LICENSE file sits at the top level of the repository and the README badge states the same, which makes the licensing position straightforward for anyone shipping the code in a proprietary application, subject to the usual obligations of keeping the copyright notice with the source.

Documentation is unusually extensive for a project of this size. The docs directory is organised by category, with integration and quickstart guides, separate pages for tweens, clips and easing, motion paths and path morphing and text along paths, effects such as stagger, oscillators, shake and wiggle and noise, colors and styles, advanced features including variations, layering, resolved tweens, anchors, drag feedback and scroll animation, and a tools section for the inspector and the profiler. Each doc is described as including code examples and API references.

The one structural caveat is that the engine is not packaged. There is no package manager entry in the listing, so adoption means copying im_anim.h and im_anim.cpp and accepting that you now own an upstream merge.

Editorial conclusion

ImAnim suits developers with an existing Dear ImGui application who want hover fades, staggered entrances and timeline clips without hand-rolling a state machine, and who are comfortable copying two files into the project. It does not suit teams that need a packaged dependency manager entry or a fully working Metal backend today, since the README states the Metal configurations compile but do not run. Before adopting, check the version badge, which reads 1.0.0 and matches the release dated 2025-12-12, read the docs on anchors and resolved tweens if your UI resizes or its targets change per frame, and confirm your Dear ImGui version is one the integration guide in docs/integration.md covers.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. soufianekhiat/ImAnim on GitHub