Interesting. What would happen if you turned on caching and made setAttribute always invalidate the cache of the associated clip?
On 2006-03-14 11:45 EST, Henry Minsky wrote: > The Flash playe re-renders the entire scene every frame, so > definitely more > movie clips will slow things down. > > The Flash 8 player has a flag on MoveClip to tell them to cache their > bitmaps, which should result in much better performance (I tried it > with the > drawing API, and it had a pretty dramatic effect in the refresh > rate for > complex drawings). I tried turning it on on all movieclips but bad > things > happened to LzText instances among other things. But as an > optimization, I > would like to look at where and under what conditions it makes > sense to > enable/disable that flag in the view system. > > On 3/14/06, Neil Mix <[EMAIL PROTECTED]> wrote: >> >> I think this is unreleated, but I'll throw it out anyway to see if it >> rings a bell: >> >> I recently spent a lot of time looking into something similar to >> this. I discovered that my application was using 25-30% CPU when in >> a steady state doing *nothing*. After extensive simplification, I >> discovered that CPU usage of a Flash app in a steady state is >> correlated to the total number of movie clips in the app (whether or >> not they contain or do anything) -- the more movie clips, the higher >> the CPU usage. It is also correlated to the frames-per-second of the >> application -- the higher the fps, the more CPU that is used up. >> >> If I were to make a guess about what is happening under-the-covers, I >> suspect that Flash visits every movie clip instance when switching >> from frame to frame. The greater the number of movie clips and the >> higher the fps, the more visits it has to make and thus processor >> usage goes up. Interesting, although not necessarily a startling >> revelation. >> >> Given the relative ease with which movie clips are automatically >> generated in a Laszlo app, it does seem like it's fairly easy to >> bloat processor usage unintentionally. I'm not familiar enough with >> the LFC (nor Flash programming in general) to know whether such movie >> clip creation is absolutely necessary. It's understandable why works >> this way, but it would also be nice if there were some simple magic >> way to reduce the number of movie clips in my app; as it stands, I'd >> have to do extensive refactoring. :( >> >> -Neil >> >> On Mar 13, 2006, at 6:50 PM, Henry Minsky wrote: >> >>> I was running a test app which prints some info to the debugger >>> every few seconds, and I noticed when I left it >>> for a while, the CPU usage kept spiking when it prints. I think it >>> is due to the progressively higher cost of the debugger appending >>> text to it's buffer and computing the new scroll position. It's odd >>> because I start seeing CPU loads spiking when the print routine is >>> called on Windows of around 15% when there is as little as 30 >>> kbytes of text in the window. >>> >>> Anyway, something is really expensive here in Flash string >>> handling, either the text appending or some other operation >>> associated with the scrolling. >>> >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [EMAIL PROTECTED] >>> >>> _______________________________________________ >>> Laszlo-dev mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >> >> > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > _______________________________________________ > Laszlo-dev mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
