I don't think SharedObject would be a preferred solution. Mainly because they are persisted to disk which is completely unecessary in this case. The LocalConnection only serves as a message broker by routing events to the designated SWF:s. Events are inherently transient.
Further, are SharedObject not throttled in the same way? All timers will be nerfed to 2 ticks/second if I understood the blog entry correctly.
I don't know if sharedObject is throttled. I don't think it was listed and
it seemed like if you are using events then you may get them more frequently
than the lowered frame-rate.
There are only so many ways to communicate between SWFs. There is a remote
SharedObject if you have Flash Media Server available. You could have a
socket server somewhere as well. You can write one in AIR 2.0 these days.
You might ask Tinic on his blog what he'd do in your situation.
Using a remote server is not an option. We are talking about local SWF:s in a browser here so that would be totally uncalled for. Not a very good solution for mobile devices either bandwidth speaking.
SharedObjects carry with them more constraints; blocking, allowed diskspace etc. which I would rather avoid. Plus, if you relied on a stable LocalConnection you then need to rewrite major parts of your application. We might have to look in to this anyway to get around this, which means an application that will constantly write on disk instead of memory (which is good for performance?).
I firmly think that you need to add an opt out for the throttling. The 'abuse' argument is invalid imho since this is the way it has worked since day 1, it is pretty assumptious from my perspective to change this behavior over a day without offering an opt out (at least for a longer grace period).
Have you made any assessment on the implication of the existing applications out there? How many applications will be affected by this? I know at least two big game companies who's games are now broken in 10.1.
note: I did try to post on Tinic's blog, but the comment system is not working. Error 404.
I too am experiencing severe performance problems with Flash player 10.1, My app has two native windows - the second one playing video. Under FP 10.1 there seems to be memory leaks, stuttering video, inability to interact with the application using the keys etc etc. under FP 10 there are no such issues. I checked the Adobe Bug log for FP 10.1 and It would seem that other people are having similar problems too. I have regressed back to FP 10 and everything is working fine again now. I will await Adobe's response in the bug log before I try again with FP 10.1.
In my opinion is would appear the the CPU throttling change has had an undesirable effect.
A bug report has been filed on the throttling behavior now: https://bugs.adobe.com/jira/browse/FP-4796
I can only agree, throttling a LocalConnection without any possibility for the application to intervene seems like a really, really bad design decision to me.
Same problems here. I relied on LocalConnection for heavy communication between different SWFs across the machine now the performance is in the cellar ...
You can set the parameter "wmode" to "opaque" to prevent it being throttled, if it's a swf on a webpage.
The swf is unable to tell if it's been hidden/minimized, so it will stay at full speed.
Can Adobe please respond to explain why this bug (http://bugs.adobe.com/jira/browse/FP-4796) has been closed as 'as designed'?
My latest comment on this issue:
"I'm sorry but how can this NOT be a bug? My organisation has an online trading application which no longer works because of this issue. Like the other contributors, we rely on localConnections to pass real-time data (market prices) between Flash player instances in different browser windows. Our system needs to support thousands of simultaneously connected clients so we CANNOT use a server connection per window - why should that be necessary when the 'main' application window already has all the data?
With this new localConnection throttling feature, our end users find that if they minimise the main window or have it hidden behind another, all other visible/invisible application windows relying on data pushed through a localConnection get massively delayed. The end result is that they cannot trade because the prices they see are many seconds behind the live price. Not only that, but there is NO way to detect when the throttling is taking place and when it becomes unthrottled again. All we do at present is display a message to the user to say that their trade has been rejected because the price in incorrect (and since the trade rrequest/response passes through the same localConnection they will be lucky to see that message inside of 30 seconds!!!)
I can kind of understand the reason behind the change - unthrottled connections could in some situations be a waste of power/resources/battery life, particularly now Flash/AIR can run on mobile platforms with limited resources and battery power. But why oh why has it been so sloppily implemented? Our application is used by DESKTOP clients which have plenty of CPU resources and no battery to worry about, and yet it is completely broken by this change.
If Adobe are not going to do anything about this change, be it reverse it out completely, make it configurable or allow us to detect when the throttling occurs then we will need to completely redesign how our application works. And if we do that we may as well move to some other technology at the same time which doesn't enforce mobile device restrictions on applications that run on the desktop!"
Please could somebody from Adobe comment on this.