von Daniel am 22.Dezember 96 um 15:17:47:
zu: Perlen aus dem Strom der Nachrichten im direct_L von Daniel am 22.Dezember 96 um 02:00:59:
There's been much talk about the actorList and how best to use it. I
started out making widgets (my terminology for any active GUI component) by
attaching mouseUp and mouseDown handlers to cast members, and then, like
many others, upgraded to object oriented widgets sitting on the actorList.
This works fine for many cases, however, if you start to have more than
just a few buttons, the overhead of all those stepFrame handlers results in
a sluggish interface. The performance can be especially terrible in tight
updateStage loops on low-end machines, for example, playing streamed media
such as sound files or QuickTime. In such cases, every object on the
actorList gets sent a stepFrame message every iteration through the
loop--unnecessary code executes in a critical loop, resulting in a
performance hit.
Now you may or may not want to handle all your GUI elements while your
sound or QT is playing, but in our product we generally only play short
samples, and stop the playing if the user presses the mouse button or
presses a key. We then resume normal handling of the GUI.
I decided to stop using the actorList because most of the time, an object's
stepFrame handler gets called unnecessarily. Take, for example, a simple
button. It has two images, one to represent its "up" state, and another for
its "down" state. The button needs to change state only when the cursor is
over it. Otherwise none of its behavioral code needs to execute. Using
traditional parent scripts and the actorList, I'd code the button's
behavior in a stepFrame handler and put it on the actorList. If I have 40
buttons, 40 stepFrames will execute every time I loop in the frame or
whenever an updateStage executes, even for buttons that are nowhere near
the cursor. Now I don't have 40 buttons on stage, but I do have 4-5
buttons, and 2-3 scrolling menus (which are each composed of a selectable
field and a scrollbar, which is in turn composed of two buttons, a track,
and a sliding thumb). The point is that an awful lot of CPU time gets
wasted using the traditional actorList.
When you analyze the problem, you really only want behavioral widget code
to execute if the user does something interesting to that particular
widget, and then send stepFrames or other appropriate method calls to it.
Here's how the GUI in my project works:
Each concurrently running movie (the stage and MIAWs) has its own set of
manager objects. The main movie (running on the stage) has a ThreadMgr,
FileMgr, ObjectMgr, MemoryMgr, CommMgr, and WidgetMgr contained in a list.
I have a global handler called Yield that calls the Run handler in each of
my manager objects. Each manager does a little (and only a little) bit of
work each time it gets a Run message, simulating a threaded runtime system.
The WidgetMgr maintains a list of passive and active widgets and a sprite
registry that maps sprite channels to the widgets that use them. Each time
the WidgetMgr executes, it calls rollOver() to find out the sprite the
cursor is currently over, checks the sprite registry to see if a widget
object is using that sprite, and then calls the Run() method on that widget
if so. It then steps through the list of dynamic widgets and issues the
Paint() method on each. (No, I haven't been working in Java lately :-)
Dynamic widgets are objects that need constant refreshing, such as
animating and "smart" buttons.
I have basically replaced the good ol' stepFrame method with a smarter
Run() method that gets called only when it makes sense. UpdateStages now
quickly redraw the screen instead of also plowing through every object on
the actorlist each time. Even though you have a few more method calls to
get to a widget's Run() method, the overhead savings more than makes up for
it. After reworking my GUI code in this fashion, the GUI feels much faster
and more responsive, especially on low end machines. No wonder, only a few
dozen lines of lingo gets executed on each frame loop, instead of a hundred
or more.
I'll try to put together a small sample movie using this method and post it
on our website. I'd also like to hear how others are fine tuning their
GUIs.
W. Dana Nuon
Fairfield Language Technologies
www.trstone.com
D. Plänitz