Are you sure about retaining the separation? For 24-bit color, you can either use 32 bits per pixel, or you can force the compiler to use 24 bit per pixel, and likely run into alignment issues. If you are already using 32 bits per pixel, no extra memory is needed for embedding an alpha channel. As far as I can tell, you have already opted for 32bpp in Pixel_rgb888. If you use ARGB ordering, no conversion will be needed for ARGB -> RGB.

For my use case, I'd be much better off just using either RGBA or ARGB. RGB+A 5:6:5:(separate image for alpha channel) isn't well-supported by most libraries. Even Qt doesn't support it. Using your suggestion would be lossy, and would require two awkward, slow color format conversions, as opposed to (at worst) a single fast, in-place RGBA/ARGB conversion for a 32-bit color image.

On Wed, Mar 14, 2018, 2:38 AM Norman Feske <norman.feske@...1...> wrote:
Hi Ben,

On 13.03.2018 18:06, Nobody III wrote:
> Will do. Thanks. The only problem I see now is the Framebuffer interface
> using 16-bit color, which lacks transparency. With 32-bit color, this
> should work perfectly, and can even be extended to text rendering.

that's a good point. The color values are limited to 16 bit for the time
being. But it is actually possible to supplement the framebuffer with
alpha values, by following the convention used by nitpicker.

Nitpicker hands out virtual framebuffers where the pixel buffer is
followed by an equally-sized alpha buffer that uses one byte per value.
(there is actually even another buffer following the alpha buffer that
contains input-mask values)

A client can detect the presence of the alpha buffer by comparing the
size of the framebuffer dataspace with the bytes required for the mode
plus alpha buffer. If an alpha buffer is present, its pointer can be
computed from the start of the pixel buffer as follows:

  Pixel_alpha8 *alpha_base = fb_ds.local_addr<Pixel_alpha8>()
                           + mode.bytes_per_pixel()*size().count();

Maybe you can follow the same convention for your image renderer?

BTW, once when we will change Genode's color depth to 8 bits per pixel
(presumably sometime later this year), I intend to retain the separation
of the alpha buffer from the pixel values. So your code won't require
big adaptations then.

If you like to look at an example of using alpha values with the
framebuffer, you may find [1] illustrative. It uses nitpicker as back
end (not the framebuffer directly) but it shows the principle idea.

[1]
https://github.com/genodelabs/genode/blob/master/repos/gems/include/gems/nitpicker_buffer.h

Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main