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.
- 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.
- 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.
- 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.
