What's the standard way for UI animations?

Question

I'm working on a UI library powered by D2D, DWrite and Wic for (SDK API) Native C++ Desktop Applications (as in no XAML, no WinRT, just old school C++). I'm all set to write a windowless UI to give a more modern (as in this century look) to my C++ tools.

I'm a backender at heart so I've spent minimal time in the UI and mostly interacted with the Windows Standard & Common Controls and some custom drawn GDI stuff. Anyways, nothing fancy.

I'm currently experimenting with D2D and I'm interested to learn what's the standard way for UI animations. Like when you hover over a button making the border glow a bit, or an UI element moving smoothly as a result of interaction, or something fading from the screen. (think jQuery fade, slide and such short but meaningful animations in the economy of UX)

Thinking of this, two ways of handling animations in UI come to my mind:

• A standalone Thread handles the calculations for an animation queue while the UI thread draws the results. Each interaction would put animation jobs in the queue and the thread calculates stuff and repositions the elements before they get drawn.
• Use same-thread Timers to schedule and iterate through the animations.

The alternate Thread Worker method seems like a good method... but requires a bit of interlocking when visual properties are updated so it does not happen while actually drawing, to keep things consistent.

Now, for a single-thread UI... timers seem to be the solution. This makes sure drawing cannot overlap with animation calculations. But to me it feels so awkward. I'm very not used to the single thread way of life. :)

Is there another way? Or which method is recommended? I'd appreciate any information on existing implementations details or reading material.

PS: I'd appreciate if downvoters or those who request close would actually give a reason. (1) If you don't know what I'm asking, just carry on... this is definitely not a question for you. (2) If this seems too obvious/simple for you, answer it. --- I don't see a third reason, unless you're trolls. --- Or this is a really silly question, but as I said, I'm a decade+ backender so I can get away with it.

Answer 1

Well, Windows seems to have an API for everything. :)

I just found the Windows Animation Manager. It does not only do what I need but at the end of the page, it has some very good videos explaining UI animation concepts and how they work with the Animation Manager. And it's a set of COM objects designed for C++ use.

PS: As a bonus, it's graphics platform independent. So it works with GDI, GDI+, Direct2D...

PPS: One day later, I already sank my teeth in it and it's very good. I got graphical elements predictably moving around the screen with minimum code. And it's logic. One single issue is that it can only animate a DOUBLE value. So it has no notion or support for a POINT, RECT, SIZE, POLYGON, multiple FLOATs, PATH... etc. Once I understand how it works properly, I will wrap it and add support for the above data types and I'm done.

Answer 2

I can't tell you the standard way but the WPF way (and the Java Swing way too I think) is to have a special thread named the UI thread whose only job is to execute the dispatcher loop. The dispatcher loop is just a fancy word for a queue (with sugar). The framework would schedule a draw function for every frame on that queue. If you would want an animation you would have to schedule these tiny stepwise updates on that queue too. That is because WPF and the like don't want locking/blocking on the UI thread and they also don't want race conditions.

So to answer your question: It is neither a different thread nor a timer. It's a scheduler that executes animation steps.

Answer 3

I know it's necromancy (I do that often), plus you already accepted your answer... But you or other readers might be interested to have a look at DirectComposition. Note it's Windows 8+ only though.

Microsoft DirectComposition is a Windows component that enables high-performance bitmap composition with transforms, effects, and animations.

Answer 4

There's no standard in the GUI. C++ does not have gui either. Has threads now, though :)

• Apps like word or outlook should use C# for gui and C++ for core.
• Apps for tech and dev users in labs, and universities, and military bunkers can usually get away with simple, cross-platform gui. QT is widespread. For really simple stuff, like demos - fltk might suffice.
• Narrow purpose small tools (file compressor, torrent client, task manager) can use native winapi windowing functions. C style. Unmaintainable. Unscalable. Native to windows platform. Optimized for performance after many years.
• Video games usually reinvent the wheel and perform all gui activity inside the game using d3d.
• Apps like skype, that require the most advanced gui features like floating/dockable/tray/custom shaped/transparency/absolutely tailor made GUI whatever the cost - will probably go with something shiny from MS, like silverlight or Wic, for that matter.
• Monstrous projects are likely to choose MFC or ATL.

Likely choices would be C# or Qt for serious gui. For smaller things winapi + gdi or a small cross-platform, c++ gui toolkit.

For any non-console programming on Windows, get yourself familiar with "window procedures" and winapi message loops. Begin with creating a new default win32 project in visual studio and looking at the code it produces. Do not write like that. Just notice the following pattern:

// Handles window messages. Gets called by the DispatchMessage indirectly.
LRESULT __stdcall WindowProc(HWND hWnd, UINT msg, WPARAM, LPARAM)
{
    switch(msg) {
        case WM_PAINT: BeginPaint(...);
                       // Some GDI drawing might go here
                       EndPaint(...); break;
        case WM_TIMER: InvalidateWindow(hWnd); break;
        case WM_DESTROY: PostQuitMessage(0); break;
    default: return DefWindowProc(hWnd, msg, wParam, lParam);
    }
    return 0;
}

int __stdcall WinMain(HINSTANCE, HINSTANCE, char *cmdLine, int cmdShow)
{
    // create your gui here
    HWND hWnd = CreateWindow(...);
    ShowWindow(hWnd, cmdShow);
    UpdateWindow(hWnd);

    // Main message loop : make the gui "run"
    MSG msg = {0};
    while(GetMessage(&msg, 0, 0, 0) > 0)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return 0;
}

This is the native winapi application skeleton. It's what MFC/ATL/Qt do underneath. Winapi offers some really basic controls out of the box: window, text box, button, radio button, select button, listbox. All do basic shadows, highlighting on focus - stuff that's available since win95, but not really much more. If the gui is very modest, then you may get away with using just plain winapi for it.

As a gui library developer, the best combo is probably win32 api and com components from ms or other vendors.