amenity*blogging

Keep on running…

Based upon a blog post by Ted Patrick from a while back, Sean Christman now shared some interesting and pretty amazing thoughts on the FlashPlayer 9 racetrack (AVM2 respectively).

The mataphor racetrack, or – to name it in a whole – the ‘elastic racetrack’, symbolises and visualises the way FlashPlayer handles the execution of (core) code, the pipeline of visual rendering, the processing of (player) events and – obviously – the execution of user code.

Now why is this being considered an ‘elastic’ approach..? This one is pretty straight forward: as per default, FlashPlayer runs through a defined set of ‘slices’ during each render cycle. Having the execution times of past cycles in memory, it determines a strategy on how to optimize this execution in subsequent cycles. Then, on the fly, the player decides to give one or another of these slices more time to complete its tasks. Regarding this, the racetrack in a whole is dynamically adopted, giving one or another slice more time to complete and therefore ‘elastic’.

So, for example, if a certain piece of code takes a lot of time to complete (assuming rather ‘complex’ code here), the player takes note of it and supports the code by giving more room for the particular slice in the next cycle. Farely, this – to be exact, the actual rendering – depends on the frame rate set by a developer. This works the other way round, too – given rather complex rendering tasks, code execution won’t have enough space and might be delayed.

Go on reading the complete article over at Seans blog.

And thanks Sean for sharing this.

Cheers, Thomas