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.