To get antialiased type to render right on 16 as well as 32 bpp, some new
BitBlt modes are needed. For instance the RGB modes are not symmetrical for
16 and 32 bits. Instead of allocating new mode numbers for this and
requiring new VMs, I was considering this:

What about adding only one new mode, which takes as an argument a pointer to
the function of the *actual* mode. Such a function might then reside
anywhere, eg. within a plugin. This seems to add a lot more mileage for the
future, since you can then extend BitBlt without changing the VM itself. And
with the jitter, who knows, even using Smalltalk methods may be fast enough
(yeah yeah, JITBlt, I know).

Of course, with Tim's new pluggable VM, one might also place all graphics
stuff in a plugin, so that you'd only need to swap that plugin to extend
BitBlt. (Saves a few lousy Ks for a headless VM too.)

Doing both of these seems the most desirable way, in fact.

If this sounds like a good idea in the first place (feedback please), some
questions still arise:

1. Andreas claims that MacOS (Code Fragment Manager) adds substantial
overhead for calling functions via pointers. This might exclude the first
solution. 

2. Andreas new BitBlt architecture is somewhere in the pipeline. How would
we coordinate this?

Henrik