Library Isolation

[Nobody III]

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 at ...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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180314/89b91dd7/attachment.html>