That's great. I can imagine this was a huge amount of work, trying to be sensible about background resources and not break existing content. (I suspect _some_ content will still be broken, e.g., someone who wrote code that expected events to happen on exact intervals.)
This will _not_ be an issue for OL, AFAIK, because our event system already expects there to be some jitter in events. For instance, animators request events at a high enough rate to give a smooth interpolation, but when an animator receives an event, it calculates the actual motion it will make from the actual time elapsed since the last event, _not_ on the delay it initially requested. Thus, an animator that expects to run for 5 minutes, that you put in the background for the middle 2 minutes, will still take 5 minutes, even with the interval timer artificially slowed. The one possible glitch I can think of would be when you bring an app to the foreground, there could be an edge case where an interval might get delayed by 1/2 a second, depending on exactly how the player handles the transition from the 2hz idle to the normal idle. If they are careful, they will ensure intervals that cross the boundary between the two idle rates get appropriately handled. Bottom line: It sounds to me like they have already done all the work for you as far as throttling down the idle loop appropriately. I can still imagine there might be something your app might want to do differently in the background and foreground, so maybe this event should be surfaced through a new LFC API; but I can't think of anything I would do differently in the kernel itself. On 2010-09-04, at 11:47, Raju Bitter 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.]
