There has been major change in the way Flash handles timing for the 10.1
release of Flash Player for desktop browsers as well:
http://www.kaourantin.net/2010/03/timing-it-right.html
In Flash Player 10.1 SWFs on hidden tabs are limited resource wise. Whereas
they would run at full speed in Flash Player 10.0 and before (note though
that we NEVER rendered, we only continued to run ActionScript, audio
decoding and video decoding), we now throttle the Flash Player when a SWF
instance is not visible. Doing this change was not easy as I had to add many
exceptions to avoid breaking old content. Here is a list of some of the new
rules:
Visible:
- SWF frame rates are limited and aligned to jiffies, i.e. 60 frames a
second. (Note that Flash Playe 10.1 Beta 3 still has an upper limit of 120
which will be changed before the final release)
- timers (AS2 Interval and AS3 Timers) are limited and aligned to
jiffies.
- local connections are limited and aligned to jiffies. That means a
full round trip from one SWF to another will take at least 33 milliseconds.
Some reports we get say it can be up to 40ms.
- video is NOT aligned to jiffies and can play at any frame rate. This
increases video playback fidelity.
Invisible:
- SWF frame rate is clocked down to 2 frames/sec. No rendering occurs
unless the SWF becomes visible again.
- timers (AS2 Interval and AS3 Timers) are clocked down to 2 a second.
- local connections are clocked down to 2 a second.
- video is decoded (not rendered or displayed) using idle CPU time
only.
- For backwards compatibility reasons we override the 2 frames/sec
frame rate to 8 frames/sec when audio is playing.
Check the screenshots at the bottom of this blog post, where you see
memory usage and cpu load or an SWF running in a visible and, and an
invisible tab.
CPU load goes down 13 from 42, memory usage goes down to 80mb from 250mb.
On Sat, Sep 4, 2010 at 2:48 PM, P T Withington<[email protected]> wrote:
On 2010-09-04, at 06:45, Raju Bitter wrote:
Is there code inside the LFC which will run into problems with such a
low framerate? Could objects be destroyed in such a case? How would
you handle such a situation within an OL app?
OL does expect to be able to set the player framerate for media playback;
but from what you say, this is _not_ affected when media is playing and you
are backgrounded.
OL also has an abstract notion of framerate that corresponds to the idle
polling rate, pretty much for legacy reasons. Depending on how the player
implements interval timers, it is possible that OL will defeat the attempt
to lower the framerate when the applications is backgrounded (since it
installs an interval timer callback at the canvas or default framerate).
Maybe the player takes the liberty of adding jitter to the interval timer
when backgrounded automatically. If not, then the OL kernel should take
notice of these deactivate events and 're-nice' itself appropriately.
[IWBRN if all players did this -- it drives me nuts when a window I have
left open in my browser that is totally obscured still sucks up 30% of my
CPU running an animated flash advert.]
