FlashPlayer 10.1 and it's implications

I had an interesting read the other day when I read Tinic Uros interesting blog post Timing it right. First of all it was very interesting to get a confirmation of how the Flash Player main loop works. It is basically a polling loop run 120 times per second. It checks timers, local connections, video, audio, frames and actionscript and handles each of them in sequence before doing an update of the screen if necessary. I'm still not 100% clear on how this ties into the FPS you set in your movie. Does it still poll 120 times per second even if you run your movie on 2 FPS?

Anyway, what really caught my attention and got me worried is the way the new Flash Player handles SWFs on hidden broswer tabs/windows. It basically puts hidden SWFs into hibernation by limiting FPS to 2(!), decreases timer intervals and local connections and video. The thought behind all of this is basically sane. There are way to many sites that are massive resource and CPU hogs just because they are running badly written Flash banners or apps. It is not sensible for Firefox (and other browsers) to take up 30-40% of the available CPU time just because it is showing (or rather not showing if the window is minimized or the tab is hidden) a couple of SWFs. What gets me worried though is the implications for applications and games. As one of the comments points out:

"I am thinking about situations where I have an application that is rendering or calculating something in the background that takes longer. Typically it will show a "processing..." progress bar which will make people want to switch over to a new tab to check their mail or browse around to pass the time. Of course with the new timer this will be fatal since the calculation will go to a crawl."

I'm also worried about the limitations put onto the LocalConnection, even when visible. According to the post:

"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.".

This will essentially put an end to logging tools such as Arthropod, Alcon and DeMonsterDebugger that make use of local connections to get the log entries out of the door. An application that makes heavy use of logging will push out more logging entries than the local connection can handle. With 33 ms per call it's "only" possible to do about 30 log entries per second, and that may not be enough for some applications. I am very pleased that use a flexible logging framework at work, and for a couple of years now use the SOSmax socket server logger.