I wrote:
> >    The main problem with animations like this 
> >   (besides sub-optimal compression) 
> >   is that you can't control the speed of the playback

Bird replied:
> i agree that the speed issue is the main one.
> 
> but what about the compression one?
> if you used the right color _mode on the copybits,
> so only changed pixels were copied over,
> the pict should be as small as it could be, not?

I'm not sure.  If you did it strictly by means of COPYBITS, I would
think that each "frame" would be stored as a full pixmap, rather than
something that says, "just change pixels 7, 223 and 457 to green."  On
the other hand, you can also record other (less space-intensive) drawing
commands than COPYBITS, and do your animation that way.  I don't know
enough about how COPYBITS works to say whether it's smart enough to
record only a "partial" pixmap.

> >   Theoretically, I guess you could use Picture Comments 
> >   to put a delay feature into them.
> 
> would that kind of delay be independent of machine-speed?
> if so, that would be significant.  but i presume not.  rick?

The technique I had in mind would be independent of machine speed.  You
can define picture comments however you like, so you could, for example,
insert after each frame a picture comment that said something like,
"delay 1".  Then you would have to write a QuickDraw hook that would
"catch" and interpret picture comments every time a picture was played
back.  When your hook routine sees the comment, "delay 1", it waits for
1 time unit (e.g., 1/10 second or whatever) before continuing.

Of course, the goal is to have the animation be nearly automatic.  If it
requires too much extra programming to support it, one might as well use
QuickTime instead.

- Rick