> In the course of those discussions, we eventually came up with the
> Treaty of Denver and the ideas that now exist in the FXBLT code ( I
> think - I haven't had time to even properly read the code yet) and
> should allow us to arbitrarily mix big-endian, little endian,
> middle-endian (yes it exists - dear old M$ does Windows bitmapts in
> middle-endian form!) as source, destiniatio, texture, halftone,
> whatever. It also allows bitmaps to be external to the Squeak object
> memory, so that memory in accelerator cards can be used.

Yup. That's the whole point. You can basically use any OS bitmap from within
Squeak with FXBlt. What you have to do is to implement about 5 C support
functions for the OS bitmap, register the thing with the surface plugin and
then you can blt from and to as you wish. No more byte reversals ;-)

> Sometime soon, VMs can be updated to make use of this and the
> pixel-swapping code will be removed from the Acorn, Windows and Unix
> windows files.

It's really trivial to do. All that's needed is to implement a couple of
primitives that actually create the bitmap (see the B3DDisplayScreen for an
example of those).

> Oh, and in most cases, the reversing loops you mentioned spend all their
> time reading from and writing to the cpu cache, so trying to do clever
> things by readinga word and hand manipulating instead of reading each
> byte separetly has no actual benefit. Been there, wasted my 
> time on that....

Ah... that actually depends. If you're doing a copying reversal you might be
right. But for an inplace reversal it *does* make a difference. Been there,
tried that ;-)

  - Andreas