From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Fri, 7 Aug 1998 13:06:25 +1000

Re: ggiGetPixelFormat and proposed new DirectBuffer scheme

Marcus writes:

>  Anyway I suggest we add
>  #define GGI_BYTEREV16(x) ((x) = (x)<<8 | (x)>>8)
>  #define GGI_BYTEREV32(x) ((x) = ((x)<<24 | (x)>>24) | \
>  			(((x)<<8 & 0xff<<16) | ((x)>>8 & 0xff<<8))

I would rather they were just:

  #define GGI_BYTEREV16(x) ((x)<<8 | (x)>>8)
  #define GGI_BYTEREV32(x) (((x)<<24 | (x)>>24) | \
  			(((x)<<8 & 0xff<<16) | ((x)>>8 & 0xff<<8))

without the '='.  Proggies can always do "blah = GGI_BYTEREV(blah)"
(and a good compiler should still be able to optimize that case, even if
we make them ASM inlines).

>  > Taking all this into account, the subschemes would now be :
>  > 
>  >     #define GT_SUBSCHEME_STANDARD         (0x80 << GT_SUBSCHEME_SHIFT)
>  > 
>  >     #define GT_SUBSCHEME_REVERSE_ENDIAN   (0x01 << GT_SUBSCHEME_SHIFT)
>  >     #define GT_SUBSCHEME_HIGHBIT_RIGHT    (0x02 << GT_SUBSCHEME_SHIFT)
>  >     #define GT_SUBSCHEME_PACKED_GETPUT    (0x04 << GT_SUBSCHEME_SHIFT)
>  > 
>  > when GT_SUBSCHEME_STANDARD is not set, then the mode is something
>  > unusual and encoding pixels and get/put buffers is not possible.
>  > (and 0 is GT_AUTO of course).
>  
>  get/put buffers are always possible (as long as the display has
>  the notion of pixels at all ;) but you have to use
>  ggiMapColor/ggiUnmapPixel to encode/decode them if 
>  GT_SUBSCHEME_STANDARD isn't set. Maybe that's what you meant?

Yeah, the *encoding* of the buffers has to go through
ggiMapColor/ggiUnmapPixel when GT_SUBSCHEME_STANDARD is not set.

(It probably will be set 99.99% of the time, but it will come in handy
for anything really unusual.  HAM6 comes to mind).

>  > OK.  Linked lists would be nicer, so that targets can take the
>  > direct-buffers created by generic-linear-*, and moved them from private
>  > to public list.  (NB: default would be private, and targets that want to
>  > export them could e.g. call _ggiExportDirectBuffers).
>  
>  Linked lists will be slow when you have a couple of buffers and
>  some driverlib has to look up a property in one of the buffers.
>  (Perhaps it needs the write-address to put just a single pixel)
>  
>  Moving buffers is non-performance critcal and can therefore be
>  done with:
>  buffers = realloc(buffers, numbufs+1);
>  buffers[numbufs] = privbuf[idx];
>  memcpy(privbuf+idx, privbuf+idx+1, numpriv-idx-1);
>  privbuf = realloc(privbuf, numpriv-1);

Guess I'm linked list fanatic :), but yeah the above will be fine.

>  MODEX/Y is defenitely a separate buffer-layout.
>  And HAM6/8 is easily dealt with by adding a GGI_PF_HAM flag
>  to the ggi_pixelformat struct.

Righto.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/