Flash 10.1 Beta 3 paves the way for a less resource hungry Flash
For every brilliant web application such as Autodesk Dragonfly or Splashup, there are ten poorly designed advertisement banners which avoid best practices and zap up resources on a page. More than anything else, they are responsible for giving Flash a bad reputation.
Not only is it bad enough that they suck your computing resources when you are on the page, however the nature of Flash is such that they will continue to suck resources even when they are in a background tab! As Flash 10.1 continues the process of optimizing the Flash runtime, Adobe has made quite a few changes to the way Flash works and in its timing mechanism such that it is expected to use significantly less resources when in an inactive tab.
An overhaul of how Flash handles timing can now have a drastic impact on the performance of Flash. In previous versions of Flash, the runtime used the browser as a source for driving the timing in the player. This meant, that while Flash player claimed to be platform and browser independent, it was still relying on the browser to drive its timing mechanism. Differences in the the way browsers handle timing meant that Flash content did not always behave in the same way on different browsers. As of Flash 10.1 Beta 3, the player uses its own timer, which is independent of the browser.
Not only is the timer now internal, but the way the timer drives the content has also changed quite a bit. The issue with changing too much in the runtime is the fact that a lot of content relies on this timing to work properly, and as such the extent to which the same could be optimized is limited to ensure that older content does not break.
Even so, the Flash player now reduces the processing requirements heavily thanks to the new timing model which retains maximum compatibility with the old mechanism. Currently, the Flash runtime works by polling as many as 120 times a second, executing the runtime code, as timed. In the new model, the timing is more dynamic, so the polling rate is dependent on of there is anything to do. This means that with content which is static, and less “eventful” the Flash player will use up significantly less CPU.
When combined with some of the changes in how Flash handles timing on inactive content, the end result is a much better Flash experience. Inactive content in now throttled, and since the new timing code is optimized to handle inactivity better, the result is that the resource usage of Flash objects in background tabs (any content which isn’t visible) take up significantly lesser resources. In order to ensure that this change does not affect old content the player now adds some exceptions for handling different types of content in different states.
As Tinic Uro explains, with the new rules, visible content in Flash will now have frame rates, timers and events firing aligned to “jiffies” (60 frames a second), except for video which will play at its normal framerate. Inactive content will be throttled down to a framerate of 2 per second and then too nothing is rendered, timers and local connections are clocked to 2 per second, and video content is only decoded — without being rendered or displayed — using idle CPU cycles. If audio content is playing, the framerate is bumped up to 8 fps to maintain backwards compatibility.
With Flash 10.1 Adobe has made the right call of optimizing the runtime instead of adding too many new features. New features added to 10.1, such as Global Error handling, globalization, multi-touch gesture support, and the other features are evolutionary changes, which bring the runtime up to date, and improve the way it works on devices. The main focus this time, is to get a proper Flash experience on as many devices as possible.
Download Flash player 10.1 Beta 3