Good to hear, thanks for the detailed feedback! On Sat, Sep 4, 2010 at 6:33 PM, Max Carlson <[email protected]> wrote:
> I've done a fair bit of testing, even forcing Flash 10 to use setTimeout() > for idle events. Everything seems fine to me! > > An edge case would be where folks are using both setTimeout() and idle > events to do precise timing. This isn't very common - both my own physics > library and the built-in animators seem to handle this fine. > > Regards, > Max Carlson > OpenLaszlo.org > > > On 9/4/10 9:24 AM, P T Withington wrote: > >> 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.] >>>> >>>> >>>> >> >>
