Index:
[thread]
[date]
[subject]
[author]
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> \/
Index:
[thread]
[date]
[subject]
[author]