130 in Safari
110 in FF
110 in Opera
100 in Chrome
60 in IE
A couple of these numbers surprise me, but this is normal behavior. Different browsers have different sized footprints. Regardless, any framerate above 50 is suspect, and likely bad practice, though you can get more out of the player now than in the past.
Why are you relying on such high framerates? Surely you can tweak the speed of the animation to do the same thing at a lower framerate.
I do not think 100% performance difference between two platforms is "normal behavior" as "Different browsers have different sized footprints".
In my humble opinion, this is poor implementation and has nothing to do with browser "footprint" (what footprint do you actually mean, btw.?). Having 4 CPU machine with 4 GB memory available on x64 machine there is no "footprint" issue affecting performance but simply poor implementation.
Then of course is the good question "Why are you relying on such high framerates?".
Yeap, taking into account Flash application loop cycle and event propagation cycle, keeping framerate high reduces idle time allowing more time for other events to execute. So, normally setting framerate to 120 fps (application maximum) let you pack "EnterFrame" events with processing-intensive code (like complicated animation) and in the result having this event time not trimmed by "idle" event fired just in a purpose to reduce the framerate to the number lower than 120 fps.
That is the same for Adobe Director - you set the tempo to 999 fps (maximum allowed) and happily you may end with your damn complex animation executed at 60 fps, while in case you initially set the tempo to e.g. 60 fps you would end at 40 fps because of processor time "stolen" by idle events.
So, normally - stetting application tempo to maximum allowed FPS should result with actual performance only limited by actuall processor power of the target platform and complexivity of your application (animation). Consequently - this opens way to real-time driven programming style, where you set event time in milliseconds not frames using internal timers what result with more fluent, more smooth animation on fast machine and more jaggy on slow ones, but both animation last the same amount of time.
This is of course all valid in case all target platforms deliver similar performance. But in case one but important target platform lags like hell - this render entire way of thinking invalid as you simply can't deliver jaggy animation for important target !
1. Plug-in versus ActiveX - that is likely the difference creating the performance gap between FF and IE. ActiveX is just not as good.
2. Read the following thread which follows this exact same logic. http://www.kirupa.com/forum/archive/index.php/t-248504.html
Thank you for the link - I would say indeed, the guy faced the same issue...
But I can't agree ActiveX architecture is natively less performing than plugin architecture. I am Windows geek and I can't confirm so. Actually, ActiveX control is really like independent module running in kernel mode (so it's security issue) rather than user mode what is the plugin case, but it has really nothing to do with performance.
In my humble opinion it's implementation problem - inside core of the ActiveX Flash Player. Please notice there is no issues like this with e.g. Shockwave Player where both IE and FF render Shockwave presenations at comparable speed.
Consequently - if that's not a bug, then it's a nasty issue... Sould be fixed one day by Adobe...