I'm not sure that all the changes Adobe has done for Flash 10.1 will leave OpenLaszlo and LFC unaffected, since throttling down to 2 fps is quite a change for the whole application. Has anyone done some testing?
On Sat, Sep 4, 2010 at 5:47 PM, Raju Bitter < [email protected]> wrote: > 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.] > >
