|
|
|
Forum Newbie
Group: Forum Members
Last Login: 5/23/2008 1:21:47 PM
Posts: 6,
Visits: 8
|
|
| OK, I "patched" Column2D.swf so it has a rate of 20 fps. Now I can display 40 of these on the same page in firefox with my CPU level around 6%. (still a bit high in my opinion, but this is much better than the previous 100% with firefox hanging) Regards,
Bernard.
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 7/22/2008 3:50:41 PM
Posts: 14,
Visits: 30
|
|
Hi Bernard,
How did you modify the swf file to make that change?
I'm looking for any workable solution at this point.
--Gregor
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 5/23/2008 1:21:47 PM
Posts: 6,
Visits: 8
|
|
I use a home-grown java tool based on a third-party library (JavaSWF2 - BSD license). This was just a proof of concept to test the theory.
This is really easy to change from FusionChart standpoint. They only have to change a single parameter. At least that is true for most of the charts. (Some of them, like the Pyramid, is basing their "animation" on the framerate which explains why it got random speed in the first place (some browsers limit the framerate)).
Now that we know it is easy to fix, I hope FusionCharts fixes it quickly.
|
|
|
|
|
FusionCharts Team
Group: Administrators
Last Login: 10/3/2008 2:42:18 AM
Posts: 2,117,
Visits: 498
|
|
But in FusionCharts, when the chart has been rendered, the FPS actually drops to 0, as the last command in the chart is stop(), which prevents any more frames from running.
Thanks,
Pallav Nadhani
FusionCharts Team
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 6/25/2008 4:20:42 PM
Posts: 2,
Visits: 9
|
|
Even so, Pallav, when multiple charts load at once, it is enough to crash a browser. It would be unreasonable to chain the loading of the charts, to make one load after another's animation stops. And it still remains that 120 fps, or even the browser-limited maximum frame rate is unnecessary for chart animation.
We have been having this problem as well, and many of our clients' browsers do not survive a dashboard with eight 100x100 px charts. It is likely that the problem is aggravated by poor flash-browser integration (as seen by a higher CPU spike and constant CPU load in Firefox, than in IE), and thus is not entirely the fault of FusionCharts, but please do what you can to alleviate this issue for your paying clients. Please limit the frame rate to something more reasonable. At the very least, please expose this parameter for runtime xml configuration with a sensible default.
Thanks,
Ryan
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 5/23/2008 1:21:47 PM
Posts: 6,
Visits: 8
|
|
I do not know the full theory behind it, but in practice, there seem to be a problem. At least this is what I was experiencing. It may not apply to all.
On my machine, when showing 8..10 charts (that appear to be static after their first animation), it really eats 100% CPU. This is very noticeable in Safari (for windows) but firefox and others are also affected. In Safari, you just monitor the CPU and as you add more chart to the page, the CPU just goes up by about 5-10% per chart. Firefox 2.0.x has another issue which aggravates this: if too much cpu is used, it actually "semi-hangs" firefox (cannot resize window and cannot access menus but hyperlinks work and you can move the firefox window).
"Patching" the fps to a reasonable level (I picked 20 fps) repaired all that instantly. Mocking with the .swf files "works" but is not an acceptable solution for me. For those that have the source (and the tool to edit it), just open the .fla file in Flash and change the fps setting when rebuilding the .swf file. But again, we would like to have it fixed correctly when we upgrade to future versions. Like a said, that fix does not work for all charts (like the Pyramid) because it seems the animation is fps-based (animation should always follow the the time, not the framerate).
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 7/22/2008 3:50:41 PM
Posts: 14,
Visits: 30
|
|
Pallav (5/23/2008)
But in FusionCharts, when the chart has been rendered, the FPS actually drops to 0, as the last command in the chart is stop(), which prevents any more frames from running.
I've been programming long enough to know that what I think is happening and what is actually happening are not always one and the same.
--Gregor
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 6/16/2008 4:43:30 PM
Posts: 1,
Visits: 6
|
|
has this bug issue been fixed? If so I need to upgrade my software...
If not, I am using FireFox 3 RC2 (The final version is to come out on June 17), and I am having an issue with CPU Usage as well. I have a dashboard with about 8 charts on it, and my CPU goes to about 50% and I can barely use FF3 at all. We are using wmode=transparent.
What can I do to fix this problem? When will it be fixed? We do not want our web pages crashing the browsers of our clients.
Thank you.
|
|
|
| | |