I've not, but as I explained in my previous reply, I think the kernel is already programmed to deal with "jitter" in the interval timer, and the way they have implemented this, it just makes your interval timer appear to have (up to) .5sec of jitter when you are in the background, so I feel we should be ok.
On 2010-09-04, at 11:56, Raju Bitter wrote: > 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.] >> >>
