On my machine I tend to see a similar CPU hit mousing over either of the first two charts.
If you get more CPU hit on the second one I can't say for certain, but my guess would be that its because you have all the vector data drawn to one displayobject and at the native player level the mouseover status is probably quicker to evaluate on the first chart because each datapoint displayobject's precalculated bounds would likely be used to eliminate redundant checking against the displayobject's vector data to determine if there is a mouseover for a particular object. Hopefully that makes sense....its a guess at how the player works (nothing to do with actionscript or flex) but I don't really know, and I don't experience that difference when comparing the first two myself.
Hard to say for sure without getting a debug build and putting it in the profiler. One possibility is that logic starts running looking for tooltips to display.
Flex SDK Developer
Adobe Systems Inc.
@Alex did you mean a debug build/profiler for the flash player itself rather than flex builder's debug/profiling for flex? Well I guess as an Adobe employee you're closer to being able to do that than I would be lol. That's what I was talking about- more the player level considerations.
The example that was highlighted as being more cpu intensive was the non-charting one where all the drawing API is going into a single UIComponent, so I'd assume it's not tooltip related, wouldn't that be more a potential issue with the charting example?
No, I was talking about using the Flex profiler. You'd have to make a debug build of the example if it isn't one already.
I'm unclear if you are moving the mouse or whether, once you've moved the mouse over the chart the mouse is now stationary. If the latter, I don't think the player should be running anything unless someone has set up a frame event or timer handler.
Flex SDK Developer
Adobe Systems Inc.
I have noticed that different browsers (presumably reflecting different plugins) behave slightly differently. For example the Safari plugin seems on the whole to run at a higher CPU level than the IE or Firefox ones. This is a qualitative perception rather than profiled or anything, but it may be worth looking at the wider environment to see what is going on.
@Alex: I assumed that in terms of code what was there was basically it - inside the Application, perhaps that is wrong, but there are not frame or timer based events in the code that's shown. And I had assumed the original observation was with the mouse moving, although it would be good to get clarification on that, I certainly get very low cpu with the mouse in a resting state over each of those examples (win, firefox).
On windows the flash player has cpu spike whenever you move the mouse over interactive content, particularly if you move it continuosly. But this is true of other windows applications as well, not just the flash player. I am reasonably familiar with one approach for what might be involved at the vector level inside the player for checking mouseover evaluation, so could understand why that might play a part in the spike, which was why I made my earlier comments. But I certainly don't know the player internals. Sure it could be something in the flex framework, but I suspect it could be player related here. I guess it hinges on your question about whether it was with the mouse moving or not.
And as Richard points out there are definitely performance differences across platforms and browsers.
I'm running on win xp inside firefox 3.0.10 with flash player 10 plugin.
After the 'generate dat set' button is pressed and the plot is complete, I move the mouse into an EMPTY grid location and DO NOT move the mouse again.
The cpu usage shoots to about 50% and stays there.
The same happens if I download the example code and run it from eclipse (debug or not).
There is only a resize event in the UI as far as I understand.
(And I made a slight mistake, it happens in BOTH examples).