Henrik,

For the short term, I think the best way to handle this is to simply add a
combination rule. The tricky problem in what you're proposing is mainly that
you have to expose a C function pointer to the ST level and personally I
don't like the idea too much. It's also not quite clear to me how useful it
is to have some specific 'combination rule' residing in a (possibly missing)
external module - how would one work around this?!

As for a more general solution, I would think that what you *really* want
here is some sort of special domain language, e.g., a language that's
specifically designed for image operations so that you can do arbitrary
image manipulation. Ideally, you would derive this from an ST method so that
you can actually use the bytecodes from the Interpreter and just compile it
natively into something highly optimized. Most of the work is probably to
identify the messages you can usefully send in some primitive code and with
a little more specification of the data types you should be able to produce
quite efficient code.

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

You can't know before you try. While the overhead is substantial you are
already paying it in BitBlt (since BB does call the functions through
pointers). However, since your CB function is likely to reside in some
plugin anyways, you will have the overhead on pretty much *any* system (not
just Macs, although it might be most noticable there).

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

That certainly depends on whether or not we really want to put some naked C
function pointer into BB. As I said, I don't like the idea too much...

  - Andreas

> 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
>