paper: animation support in a UI toolkit

Here's a back-post for a prelims paper: "Animation Support in a User Interface Toolkit", by Hudson and Stasko. I thought this paper particularly relevant, as I'm currently working in interactive graph visualization, which includes a heavy animation component. This paper got me considering higher level primitives I might use in the graph viz toolkit we are developing.

Animation Support in a User Interface Toolkit: Flexible, Robust, and Reusable Abstractions
Scott E. Hudson, John T. Stasko
UIST'93 (User Interface and Software Technology 1993)

In this paper, the authors present extensions to the Artkit user interface toolkit to support animation. The toolkit offers basic support for simple motion blur, "squash and stretch", use of arcing trajectories, controlled timing of actions, anticipation + follow-through, and slow-in / slow-out transitions. It also supports a robust scheduling system that helps deal with unpredictable performance from the windowing system... very important since this was running on X-Windows.

The main abstraction used is the transition, which consists of a pointer to the UI component that is moving, the trajectory the component will take, and the time interval over which to animate. The UI component can be any interactor object implemented in Artkit. The trajectory consists of the curve traveled (parameterized from 0 to 1) and a pacing function to determine velocities over the curve (e.g. using a line with slope 1 for uniform animation and an arctan or sigmoidal function to create slow-in / slow-out transitions). The times in the time interval can be expressed as absolute times, as a delay from the present time, or parameterized by the starting or ending of other transitions.

Robust animation and event-relative transitions are achieved using an animation dispatch agent. All that is assumed is that the tookit can ask what the current time is and that the window system will pass back control to the toolkit periodically. The agent constructs a scheduling queue of transitions, and attempts to estimate when the next draw cycle will appear on the screen using a measure of past updates. Using this redraw end time, the set of active transitions for the current cycle is selected. For each active transition, it is started or stopped as appropriate and current parameter values are passed through their pacing functions and mapped to screen positions using the trajectory.

This scheme will animate smoothly when the agent is given control at a regular intervals, but it will also properly handle delays, correctly delivering animation steps at larger intervals.

Criticism: The first thing that struck me is that no mention of scale is given. How many objects can I animate at once? What are the bottlenecks? Obviously rendering time is a major factor, but overhead is accrued through scheduling and through mapping each object through it's own pacing and transition items. In most cases I'd expect this to be a constant time overhead, but this isn't really discussed. Also, cool animated effects like squash and stretch was mentioned multiple times but the implementation of it is not discussed.

Today, 10 years later, we have incredibly more powerful processors and graphics cards, enabling much richer animation possibilities. This paper was ahead of it's time and today's popular toolkits - Swing, MFC, etc - are definitely behind the times. While toolkits like Java2D provide much of the rendering and geometric capabilities needed, animation managers like the kind presented here and in Xerox PARC's Information Visualizer are yet to be common. Hopefully as graphics power continues to grow and the drive for more powerful interactive technologies gains momentum (e.g. more widespread use of information visualization) these more powerful tools and abstractions will become commonplace.