timelinelite/max accuracy

[andytwoods]

Wow, seems my views on how flash adds things to the display and then shows them on screen were not quite right. I only use code and don't use the timeline. I always thought adding a child to the display displayed it immediately but I now believe it is only added on the next frame.

 

My q now is: if I ask timeline lite to show a sprite after 10000 ms, how precisely will it do so? Would it more accurately be displayed after 5000ms? I wonder if there timing errors accumulate in flash and whether timeline lite compensates for them.

 

Sorry if this is a silly q

Thanks Andy

 

---Original message

Hi there,

just wondering about the timing accuracy of timelinelite. I bet you have thought of and implemented everything to make things as accurate as pos but just to reassure me before i replace my own timing classes with yours, do you refer to system time regularly to update any timing wanderings?

 

I am betting your timelinelite is a bazillion times more efficient and more accurate than my own home hashed hacks!

 

Thanks Andy.

[jamiejefferson]

I always thought adding a child to the display displayed it immediately but I now believe it is only added on the next frame.

This is how flash is going to work regardless of your timing tool unfortunately. If for example, frame 300 occurs at 9999ms, and at 10000ms addChild is called, then that DisplayObject will not be drawn on screen until frame 301 regardless of if it's drawn at 10000ms or at 10030ms.

 

I think any issue with 10000ms not lining up 100% exactly with the instant a child is seen added to the stage is going to be influenced far more by framerate and flash's internal processing/rendering time, and not the greensock timeline.

 

Unless 10000ms lines up exactly with a frame being drawn (and assuming that flash adds the child to the stage and renders it in under 1ms), then you will theoretically have a maximum margin of error for the 'addChild' equal to 1000ms ÷ current FPS. e.g. at 30 FPS there should be a frame drawn every 33.3ms, so your child may not appear until 10033.3ms. This margin is going to fluctuate constantly though, as things like flash rendering and flash garbage collection can cause the FPS to change frequently.

 

I can't really speak for possible 'timeline drift' over time, if that's what you are encountering, as I've not bothered to read to the depths of how the greensock core is running. However I am certain that Jack would have considered all solutions, and that the most accurate timing is available in Greensock, considering that's a main feature for a timeline platform. I've not encountered it myself yet.

[GreenSock]

I don't think I could explain it any better than Jamie. I just wanted to chime in and confirm that yes, the animation platform is extremely accurate in terms of time - it literally checks the time on every frame update and that new time drives the update of every tween across the board. And they are all perfectly synchronized too. There is zero drift. And all of the updated values for each tween are dynamically calculated based on the precise current time. So GSAP tweens are FAR more accurate than MovieClip timelines that were built in the Flash IDE which have a fixed resolution (time-wise) and can drift drastically if/when the frame rate isn't perfectly maintained during playback.

 

The only exception to the "no drift" rule for GSAP, of course, is for any tweens (or timelines) that you set useFrames:true in which case it only cares about the number of frames that have elapsed instead of time/seconds. But the default mode is time/seconds.

 

I am not aware of any timing technique that would be more accurate than the one that's already in GSAP. In fact, one of the most critical pieces of the platform, and the thing that a lot of effort went into was the core timing mechanism and the architecture that keeps all the tweens perfectly synchronized (that's somewhat of a rarity among tweening engines - try creating 10,000 tweens on the same frame in another engine and you'll typically see drifting occur between the first and last). If you (or anyone) have any ideas for improvements, I'm all ears. But I can't remember ever hearing a complaint about inaccurate timing in GSAP, so you can rest assured that things are solid under the hood. Check for yourself if you want

 

Good question. I'm glad you asked - it gave me a chance to explain it a bit and I'm sure you're not the only one who has ever wondered such a thing.

[andytwoods]

Thanks guys

Ripping out my own timing stuff as we speak.

Greensock is awesome.