cpu usage

[mgason]

am using the flash ocx (player) embedded in a windows application.
This application is part of an industrial automation package.
Basically the aplication tells machines on the factory floor what to do.
Sensors tell the the application when events have actually occured (ram up/down, door open/close etc)
The application then communicates with the embedded swf and tells it to display the appropriate animation.
The animation is modelled using autocad, swift3d and then flash and optimaze.
The movie contains no actionscript except some basic stop actions.
All commands are sent in by the VB app.
It is reasonably complex but only 120K as a swf.
It all works except for a very BIG BUT.....

The player when displaying the animation uses 100percent of the CPU power on a windows xp pentium 4 2.6 machine.
This is the case even when just running it in a projector without our application.
The Flash player hogs so much of the CPU that the main application can not run properly, communication between machines. PLC and PC are affected.

Is there a way to limit the amount of CPU the player can access? Is it something that could be done in future by macromedia?

We love the look of flash for this sort of project but every time we approach it we run into this CPU sucking black hole called the flash player!
We have succesfully used it in some apps, but only simple ones after extreme efforts to optimize the movie, such as removing all text and overlaying it in the VB app.

I am posting a movie example. The buttons will do all the things that in the real app would be controlled by incoming communications from the factory floor sensors.
http://www.visi.com/~mgason/flashstu...layer_help.htm

any thoughts?
this industrial animation could be quite an extra market for macromedia if the player wasnt such a hog.
mark

[Northcode]

If you're sucking up 100% CPU in the standalone Flash player then you're never going to see that drop when you're playing it in the OCX. The kicker is that the machine isn't really that busy so something in one of the steps you're going through to produce the final output or the way the animation is played is doing something nasty.

Can you provide any more details about the construction of the SWF that might shed some light on the situation. I'm guessing it's a collection of movie clips that are just started on the button presses or by calls to IShockwaveFlash::TPlay?

You might also want to check out one of the other forums as well since this isn't strictly a standalone problem. You might have better luck with more eyes looking at the problem.

[le spud]

I have the same problem with a button,
all the button dose is snow.

The button is only 30-26, and it dose uses %100 of the CPU,
i try to open up a window and it takes about 45 sec, which is just insane.

How can something so little chew up something so big?

(Althon XP 2.2)

[Northcode]

If you've got any ActionScript in there it can be really easy to chew up CPU if it's not done "just right". Post your FLA and I'll have a look at it for you.

[le spud]

Im using D and J Media's snow effect,

Here

go-to>
Free Flash stuff:>
snow effect with collision detection:>

[Northcode]

www.northcode.com/misc/snow.fla
www.northcode.com/misc/snow.swf

Instead of creating and removing the flake clips all the time, my version reuses them. You can specify the initial number of flakes and 100 seems to look the same as the other examples. I also optimized the code that moves the flakes a bit.

The end result is that my version runs at about 60%-70% CPU here with collision detection. The original snow.fla I downloaded used almost 100% withotu collision detection.

This was a quick hack and there are probably more optimizations you could make. One obvious one to try is using a lookup table for computing the sin instead of Math.sin(). In C a lookup table would be faster than the math library function. Whether this trick works in ActionScript depends on how well arrays have been implemented.

[mgason]

Hi,
thanks for your input.
It is a group of mc's
The majority of the image is a static single mc.
most of the animation is strictly go to a frame and stop with that frame just having a different static image. (the tanks and doors etc.)
The rotors is a mc with 6 keyframes of the rotors in deifferent positions which is told to stop and play.

The flow in each of the pipes is a mc with a mask. beneath the mask is a mc with a motion tween of dots moving. (a mc of about 30 instances of a single dot mc is motion tweened)
I deliberately avoided using any alpha here. The mc is contained inside another which is 2 positions, one blank frame, one with the flow animation mc.

The movie contains no actionscripts. From our application we simply tell it to go to a frame, or play/stop.

The flow seems to be the really big killer.
Any ideas on a way to do that without using a mask and motion tween?
mark

[le spud]

Although i haven't downloaded it yet (my ADSL if slow as) i think it might help,
so thank u

[Lorddrago]

Just wondering were you are from, this looks just like the mixer used at Eaton Aeroquip in Mnt. Home Arkansas.

[mgason]

Well where the plant is I am not at liberty to say.
That is our customer. It is not Eaton Aeroquip.

I am working for Mesabi Control Engineering who created a software package for rubber mixing automation called Mix Vision, which is installed in many mixing plants in the USA. Each package is customized for the plant. We are located in St Paul Minnesota.

So why do you know what a mixer looks like!
Mark

[Lorddrago]

Because I was a team leader and a mixer operator for 8 years at Eaton Aeroquip in Mtn. Home Arkansas. Also take a look at this tutorial on moving mc's with actionscript. Should take some strain off of your flow movie.

click here for link

[mgason]

We do have a system in Batesville Arkansas.
I know how to move it with actionscript, thanks for the idea.
I will try it, but have my doubts that a bunch of onClipEvent(enterFrame) things running will be any less intensive.
still its worth investigating.
So far 4 frames per sec is solving our problem and looks fine in this situation, in fact we have been able to add some pieces of animation.
thanks again
mark