Brian S. Julin writes:
> 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,
In these case (drawBox) the alpha is constant just like the fgcolor.
Non-constant alpha only happens with blitting objects. Another
idea would be to allow the use of the destination alpha as the
alpha value for drawing (which would actually be a good explanation
why the main fb has an alpha channel at all).
> and how to eloquently express in the API
> the difference between an alpha channel and an alpha side-buffer.
IMHO simply by setting the correct values for alpha_mask and
alpha_shift in the pixelformat. If it exceeds 32 bits, you can't
access the alpha value with ggi_pixel directly, but either thru the
framebuffer or a libbuf wrapper.
> 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.
Why couldn't you get the .a with a side buffer?
> 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.
Well, it looks to me like there is 2 approaches: context driven or 'one
shot' API. We can provide both and let the user choose the one fitting
his need.
Anyway I caught a bad cold while trekking in the rain and part of my
brain is vegetating right now. So I might have missed something.
Eric.
