Reproducing A Clever Animation Product, Part 16

Today I wanted to further rearrange the transition definitions so they more closely matched those used by the Greensock animation product I’ve been emulating. A screenshot from their demo video is shown here:

The next step is to move the duration parameter to be the second term in the addTransformToList function call(s) as shown here:

The next step is to get rid of the direct specification of the starting time in this call (currently the fourth parameter as shown above). In theory it would be a simple matter to track the cumulative starting times of the transforms from the delays (as they are specified in order) and use that information to replace the starting time parameter. I’m also going to add an adjustment factor that will allow the user to specify a bump forward or backward in time relative to where the starting time would have been. That’ll be handled with an optional item at the end of the parameter list.

The adjustment factor can be absolute, say, 0.25 seconds earlier than the default (the end of the previous transform), as shown in the second line of the Greensock demo image, above. Easy enough, right? Well, we also want to be able to specify a different basis for an offset, one that isn’t blindly based on the previous element but one that is referred to by its label. That should be simple enough–but what if the label is found in the list of transforms more than once? The Greensock demo doesn’t show a case where that happens but my scenario does. I think the tool should be able to handle that circumstance so I’m going to have to add in my own twist on things. I’m going to make the code handle labels with and additional specifier, separated from the label by a colon.

Let’s start by reviewing what we have so far.

Since the first four items are specified in order they could probably be left alone. However, transform 5, the first transform for the second element, starts before the end of transform 1, the first transform for the first element. Similarly, transform 7, the first transform for the third element, also happens before several of the other transforms complete. Indeed, there are three transforms that all end at the same time. We therefore need a way not only to refer to a transform by name, but also by which occurrence of that name.

There’s one more bit of complexity: how do we handle the cumulative starting time of transforms if they are specified in unexpected ways? The first four items in the above example are straightforward. They go in order, without delays, and each advances the accumulated start timer. Transform 5 has to be offset from the end of transform 1, and it won’t advance the timer. Transform 6 has to be based on transform 4 (or the end of transform 3, in theory). Transform 7 could be based on transforms 3, 4, or 6. Transform 8, finally, could be based on transforms 3, 4, 6, or 7.

Leave it to me to make things complicated, right?

I think what I’m going to do, since it would be most comprehensible to the user, is to base everything on transform 3, with the exception of transform 5, which has to be based on transform 1. That code would, in theory, look like this:

I originally saw that this case doesn’t allow for specifying a simple offset from the previous element (like the second transform in the Greensock demo), so I changed transform 8 to start with an offset directly from transform 7. What I have to decide now is whether to maintain a single, global start time accumulator or allow items with like handles to maintain their own, local start time accumulator. I think the former, but we shall see.

So what do I have here? Again, the first four are easy, as is transform 6. Transform 8 is now easy-ish because we are least have a straightforward place to start from. Transforms 5 and 7 combine both a reference to not only a label, but a complex label, and also an offset.

This completes the analysis, tomorrow we’ll tackle the code.