I would think so, but certainly one can't be careless about the
organization of a stack this large on such a system.
> If not, do you have any
> suggestions for making the system run better? Increasing swap space,
> etc.
Increasing swap won't make any difference. Increasing RAM probably
would, though, especially if there are any other applications running
at the same time.
Since you didn't specify which OS release (or even which OS) you're
using, nor the version of MetaCard, it's hard to make specific
recommendations. But I can make some general recommendations:
1) You should be using MetaCard 2.0.1 or later, and since it's getting
close to release, you should be testing your application under 2.1 and
making plans to upgrade to that when it is released.
2) Depending on where the performance hit is, you should be using
primarily either GIF or JPEG images: GIF doesn't compress as well and
so will slow startup times, but JPEG takes awhile to decompress which
will slow card-to-card transitions if the cards use different images.
3) If your stack has lots of screen shots taken with the MetaCard
snapshot tool, consider exporting them and converting them to GIF or
JPEG and then reimporting them. This won't help much if you snapshots
are of things like dialog boxes (which compress well with RLE
algorithm MetaCard uses), but will help a lot if the snapshots use
many colors or don't have large areas of uniform color.
4) Use the same colormap for all the GIF and snapshot images in your
stack. Most image processing packages (including NetPBM) have tools
for remapping image colors to a common palette. If you've got an
image that uses all the colors in your palette, consider putting a
hidden copy of it in a background (group) that you place on each card
in your stack. This will eliminate color allocation overhead, which
is the single largest time hit when transitioning between cards with
different images on them.
5) Use as few colors as possible in your images. The fewer colors you
use, the faster the color allocation will go, and the more likely your
stack will look right when run with another colormap-intensive
application (such as Netscape or other WWW browsers).
6) If possible, decrease the size of the stack window and/or of the
images you're using.
7) Use the "move" command instead of using "repeat" loops to move
objects around.
8) Avoid using "idle", "mouseStillDown", and "mouseWithin" message
handlers: use "send..in" and the "mouseMove" message instead.
9) Whenever possible, use opaque buttons and fields. They redraw much
faster since objects underneath them don't need to be redrawn each
time the button or field is.
10) Avoid using shell and open process. Whenever possible use
MetaCard's built-in support for finding, opening, and reading files,
and for getting environment variables.
11) Stick to a common set of fonts. Font loads take a long time, and
the fewer fonts you use, the faster your stack will run.
12) Use .au format audio. It's the smallest format and so loads the
fastest and uses the least amount of CPU time to play.
13) If you really want to cut down stack size (which reduces startup
times), consider storing images and audio clips externally. This
increases the time it takes to display the images and to start playing
the audio clips, however.
14) If possible, exit all other running applications when running your
stack. Things like xload and Netscape not only chew up a lot of CPU
cycles even when they're iconized, but by not allowing themselves to
be swapped out, they make systems behave as if they had a lot less RAM
than they really do. Use a program like "top" to see what processes
are running and how much memory and CPU time they're using.
Hope these help!
Scott
> Thank you.
>
> Wayne Aldrich
> Sterling Software
>
-- *************************************************************** Scott Raney raney@metacard.com http://www.metacard.com Tcl and ksh: syntactic gymnastics MetaCard: it does what you think