R.P. Churchill.com

Yesterday’s attempt wasn’t too bad; I needed to fix the declaration and use of the object that holds the transform information (yesterday’s form only works if you initialize the internal member values with literals) and I needed to tweak a couple of indexes. The corrected code is shown below, along with an extra function for displaying the information.

Here is how I loaded up the array. It includes a series of three transformations for the left location of the first object, but out of order. It then displays the information before sorting, does the sort, and displays the information again after the sort.

Here’s the output before the sort:

TransformList
Element: handle001
Type: left
start: 301 end: 25 begin: 0 duration: 0.75 method: linear
start: 301 end: 25 begin: 4 duration: 0.5 method: linear
start: 25 end: 301 begin: 2 duration: 1 method: linear
Type: opacity
start: 0 end: 1 begin: 0 duration: 0.75 method: linear
Element: handle002
Type: top
start: -25 end: 125 begin: 0.5 duration: 0.75 method: linear
Type: opacity
start: 0 end: 1 begin: 0.5 duration: 0.75 method: linear


…and here it is after the sort:

TransformList
Element: handle001
Type: left
start: 301 end: 25 begin: 0 duration: 0.75 method: linear
start: 25 end: 301 begin: 2 duration: 1 method: linear
start: 301 end: 25 begin: 4 duration: 0.5 method: linear
Type: opacity
start: 0 end: 1 begin: 0 duration: 0.75 method: linear
Element: handle002
Type: top
start: -25 end: 125 begin: 0.5 duration: 0.75 method: linear
Type: opacity
start: 0 end: 1 begin: 0.5 duration: 0.75 method: linear


Now that this is done I can modify the tween definition functions to write out the full and correct state of every element for every animation step.

Also, it can be argued that it’s unnecessary to specify the beginning and ending state of each transform. The properties to be transformed are already initialized, so in theory the transform functions would only have to specify what the new value should be. That would obviate the need to correctly specify the initial value of a property as being the same as the final value from then end of a previous transformation. I note that the Greensock product does this, including not just a “to” transform but also a “from” transform. If you initialize all the elements where you want them to end up you can get an idea of the final layout, and then the animation sequence can start from where you specify and end up where they were initialized. That said, one thing at a time…

I found it necessary to create a list of elements that will be transformed during the animation. Within each list of elements there will be a sublist of transform types. Within each list of transform types there will be a list of the actual transforms. Element zero of the first two dimensions of the array will contain the name of the element and transform type, respectively.

The first set of calls should be to define the transforms as the programmers thinks of them. Once all the transforms are defined the code sweeps through the list and, where it finds multiple transforms of a specific type for a specific element, reorders that list of transforms by starting time.

I’m assuming that later transforms (in list of like transforms for a given element) will determine the state of the element from their beginning in time through to the end of the animation. It will not be possible to embed transformation streams. For example, if stream A runs from 3.0 seconds to 9.0 seconds and stream B runs from 5.0 seconds to 7.0 seconds, the states defined by stream B will apply from 5.0 seconds to the end of the animation. The animation will not use the values from stream A from 7.0 to 9.0 seconds. There has to be a rule and this is the one I’m choosing. It has the virtue of being simple while also allowing anything to be done at any time.

The code will look something like this. I haven’t got time to debug it today; that will be tomorrow’s project and I’ll post any mods I make then (the chances of this being perfect as is are somewhere between zero and nothing…). Once I know this works I can readjust the previously existing functions to write out the transformation streams.

Once I get this working it should enable me to come up with a better way to specify starting times for each transformation stream. The Greensock product allows the programmer to specify starting times relative to other events and not necessarily in absolute terms, which (as they point out here) is cumbersome to keep track of and modify efficiently. The product also supports a flexible, shorthand notation for specifying transformations of increasing complexity, assuming default values for parameters not supplied. It appears to do this using function parameters in something like the object literal format.

Drawing things out graphically is always good to clarify thoughts, so I’ve done that with the problem at hand.

Here I show the array of animation steps in a shorthand form. The red areas show steps where multiple assignments are given for a particular property but only one is changing (going forward, things might look a little different going backward) and only that one should be used. The green areas show steps where multiple assignments are given for a property, none of them are changing, but only one is supposed to be used. The yellow areas show where multiple assignments might be given for a particular property but it doesn’t matter which one is used. The gray areas show property assignments that a) don’t change and b) should not be used.

This makes it clear why the bcChainFlag variable’s ability to inhibit the assignments in the upper right gray area works. It would also prevent the seconds assignments in steps 7 and 8. Inhibiting the assignments in the lower left gray areas isn’t necessary because if both are written out and executed then only the second one will affect what the user sees. We do waste operations there, however.

What we need, therefore, is a way to ensure that a property assignment gets written for every animation step, since we want to have enough information available in each step to recreate the entire visual state. We can do this in two ways.

One is to write multiple streams of commands that include blanks where another assignment should be used as follows. Running the eval statement with an empty string does nothing so we’re free to fill up the animation array with blanks. It wastes some time but it’s simple and consistent.

The other is to place updated values in the same stream of commands as follows. Either we have to rely on the programmer to specify beginning and ending ranges explicitly or we have to make the generation of subsequent streams of commands smart enough to know what to overwrite. We can do that by scanning through the animation commands to look for the stream that modifies the property in question, or we can maintain an external registry that does the search and returns the index of the array to write the partial stream to.

I think I prefer the latter option. Doing a bit of extra work up front in order to have a cleaner animation stream seems like the right thing to do.

In order to do this we’ll need a few ground rules.

1. We either have to ensure that the programmer issues the commands in order of increasing time of the beginning of each transition or we have to store information about the transitions in a list and then sort them and process them in time order. Given what I see in the demonstrations it appears that the Greensock product does this or something similar.
2. In order to keep things straight we need to limit the number of ways to affect individual properties of elements. We do not, for example, want to support six different ways of specifying the left location of an element. Since we control the ‘registry’ we can still do things in a clear and modular way.
3. This method appears to eliminate the need for specifying begin and end states outside of the animation stream itself since the first and last elements will contain all of the necessary information. This is a good thing.

Come to think of it that may be it. I’ll see how it works out when I try implementing this on Monday.

Oh, one more thing. I’ll also have to think about situations where different properties may produce unexpected results. On the other hand this is clear enough and looks like it would work in both directions.

The next logical thing to think about with the animation capability is the idea of specifying the full state of every element during every time step. If this is done then we don’t have to worry about missing animation steps with important state changes. We can use the slider to advance to random points and we can increase the apparent speed of the animation by advancing by more than one step at a time. The downside is that more data is required to specify the full states during every animation step and it becomes more difficult to manage multiple streams of transitions that affect the same property of an element. The latter of those two issues seems to be the more problematic.

Let’s think about transitions that set the location of the left edge of an element. If there’s only one series of transitions then there’s no problem; we just set the position for every time step whether the element is in view or not. If there’s a second series of transitions that start after the first then we have to figure out how to use the one that applies and ensure that it works when the animation is moving forwards or backwards. We did some of that in a simple way by setting and clearing the bcChainFlag variable but now we need to do the right thing for potentially numerous transition effects for multiple elements.

For now I’m simply going to list all the issues I can think of.

• Multiple transition types may affect a single characteristic of an element. For example, the left position of an element could be affected by setting the left value directly or by applying the style.transform CSS properties translateX(x), translate(x,y), translate3d(x,y,z), matrix(n,n,n,n,n,n), and matrix3d(n,n,n,n,n,n,n,n,n,n,n,n,n,n,n,n). Depending on the parameters used, setting the display and opacity CSS values may also have the same (or different) effects. That said, there’s no formal need to support every possible transition type.
• We have to ask how much we should try to get our framework to bail the programmer out of possibly bad decisions or how much we should make the programmers sweat the details.
• To that end we could add more parameters to the specification of transitions to allow the programmer to control the range of steps that get filled in, by a transition–even when nothing is actually changing. Here I observe that the Greensock product I’m emulating (in a basic form) allows for a very simple specification of transitions and must be doing some of this in the background.
• Right now I’m writing out full JavaScript statements to be executed by the eval() command. In theory I could accomplish the same thing with a series of codes and a giant switch statement to handle the possibilities. The latter possibility occurs to me because it might be easier to write code to process numbers and parameters directly to figure out how to resolve conflicts between multiple transitions. That said, I feel like the statement/eval() approach makes more sense because the capabilities feel more modular and independent that way. I don’t know that’s true, I just feel it–for now.
• Also the same prioritizing can be accomplished by parsing out the raw text of the JavaScript statements. In either case I’d have to figure out some kind of hierarchy of effects to know how to resolve potential conflicts.

Basically, I just need to think about this more before moving ahead.

One thing I snuck into yesterday’s code examples without explaining is a way to use different animations for the same property of the same element. The way it works now the functions that generate tween information install commands into the list of animations to perform during each step in the following way, after each element is initialized using bcInitElement function and additional functions for properties not defined therein:

1. Assign the state in the beginning initialization, in the bcInitializations[0] array.
2. Assign the same state in the animation step before the main series of transformations is to start, if the series of transformations begins after the first animation step. This is added so the element can be returned to its original state when the animation is run in reverse.
3. Assign the series of transformations to the desired, contiguous range of animation steps.
4. Assign the final transformation in the series to the “ending” initialization, in the bcInitializations[1] array. This is used to “initialize” the state of each element when the simulation is run in reverse.

All well and good, but what if I want to do a series of transformations to an element, even if they involve different properties? Suppose I want to make an element visible by changing its opacity from 0 to 1 from second 1 to second 2.5, then move its left edge from 100px to 401px from second 3.5 to second 5?

Most of it would work fine. The second initialization would start where the first left off, so the initialization for the 3.5-second mark minus one animation step would not be a problem (see step 2, above). The series of transformations themselves, described in step 3, above, also would not be a problem (assuming the animator didn’t try to overlap the transformation series in time, in which case the latter one would always be the last called). The “ending” transform, which is actually the beginning transform when running in reverse from the end, would also not be a problem, because the latter transform would be set after the first one. In that case see step 4, above.

The problem comes from step 1, above. If the second transformation is allowed to initialize the element to the spot where the second transformation ends (which should be where the first transformation begins), then it would override the initial setting of the first transformation series.

Fortunately, there’s a way around that. If you’ll notice in yesterday’s code snippets, the initial state is only assigned to the bcInitializations[0] array if a variable called bcChainFlag is not set. That means that the initialization is inhibited is that flag is set, and this is done by calling the bcSetChainFlag function.

Here are the relevant code snippets.