Charlie wrote:
> PICTURE ON/OFF records the actual QuickDraw commands that you issue and
> duplicates them when you play it back. A PICT resource simply contains a
> bitmap-like image of the display.

This isn't entirely accurate.  The picture data that's recorded between
PICTURE ON and PICTURE OFF commands is actually in the same format as
the data in a PICT resource.  In both cases, they contain a "recording"
of some QuickDraw commands.  With the right software, you can
"disassemble" a PICT resource (or a picture handle, or a PICT file), and
see a listing of the "opCodes" that stand for the different QuickDraw
commands.

It so happens that one of those commands is "CopyBits."  If you do a
"CopyBits" command between PICTURE ON and PICTURE OFF commands, then the
corresponding opCode (called "PackBitsRect") is recorded, and one of
this opCode's arguments is a huge chunk of data containing the pixels
that were copied.  In this case, 99% of the "recording" is taken up by
the bitmap itself, but it's still basically just a recording of
QuickDraw commands.  There's no reason why you can't, for example,
record other QD commands along with the CopyBits; the picture will then
contain a "PackBitsRect" opCode (with bitmap), plus the other opCodes
you recorded.

In fact, there's no reason why you can't record _multiple_ "CopyBits"
commands (each copying a different image) into a picture.  When you
played the picture back, it would flip through each recorded image, and
appear animated.  The only drawback would be (just as with animated
GIF's), you couldn't control the speed of the "frames."

- Rick