Hi,
I've reached a rough spot in the LibBuf API, and would appreciate
opinions on smoothing it over.
Currently the API supports an emulated or non-emulatd alpha side-buffer,
and will also support both emulated and non-emulated in-pixel alpha
channels. It does this by overloading the visual's drawops, and
providing a graphics context (one for alpha and one for Z) which
supplies a constant alpha/Z value to represent the source alpha/Z
when a primitive is invoked, so the command:
ggiDrawBox(vis, x, y, w, h) will draw a box with a constant source
alpha, and the destination alpha taken from the alpha buffer or
channel.
The question is -- how to provide support for non-constant alpha
values in the source, and how to eloquently express in the API
the difference between an alpha channel and an alpha side-buffer.
The problem centers around the fact that when you are using an
in-pixel alpha value, ggiUnmapPixel/ggiMapColor can use the
color.a field, whereas when you are using a side-buffer, there is
no guarantee that you will be able to stuff the color.a field into the
pixel. I thought about changing the pixelformat when the alpha
buffer is added to a pixelformat that has an alpha channel, but that
strikes me as messy and it would break when the total exceeded 32 bits.
The better solution in my mind is to provide a GC flag that enables
use of the source alpha -- this would work for all targets with
copybox, but with the put* primitives it would only work for
in-channel alpha. What I could do is provide two flags, one to
turn on the copybox support, and the other which is documented to
only work for in-channel alpha, which turns on suppot for put*
primitives. I am leaning this way now.
An alternative solution is to provide additional drawing primitives,
e.g.:
ggiBufPutBox(ggi_visual vis, x, y, w, h, ggiBuf_t srcalphas, void *srcpixels)
And a person with in-channel alpha would use this function, but could
leave the srcalphas parameter == NULL. The advantage is that the API
is more unified across different target visuals. The disadvantage is
that it would require a good amount of additional code to emulate
the srcalphas parameter on a in-channel visual when the user opted
NOT to provide a NULL.
I just want this to not look like a bag on the side of GGI, so if
anyone has any suggestions for an API that will make this clear and easy to
understand to the user, that would be great.
--
Brian
