Library Isolation

[Norman Feske]

Hi Ben,

I am afraid that we are getting off-topic but I nevertheless don't want
to leave your question unanswered.

On 14.03.2018 19:40, Nobody III wrote:
> 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.

with using 24 bits per pixel being no option, the obvious downside of
using 32-bit color values combined with a separate alpha buffer is the
waste of the forth byte of each 32-bit pixel value.

For this reason, I shared your intuition before I practically explored
both alternatives. In particular with my work on the menu view - which
uses 32-bit color depth internally - I first went for the RGBA
representation where the alpha values are interleaved with the color
values. However, the complexity of the result made me uncomfortable,
which prompted me to split the alpha channel from the color values. This
change had the desired effect of vastly simplifying the
software-rendering code while making it more flexible.

In hindsight, it is obvious why: Alpha values and color values are
different things. Pretending that an alpha value is a forth color
channel is a leaky abstraction at best. It turns two simple but
different (!) objects (color and alpha) into a more complicated object.
All operations on those objects are then bothered with the semantics of
both parts. E.g., in practice, one wants to have the freedom to apply an
operation only on the alpha channel. With RGBA, one needs to craft a
special operation for that. Worse, since this policy is part of the
inner loop of drawing operations (similar to a pixel shader), the logic
around it needs to consider both color and alpha - even if only one part
is used by the operation. In short, by keeping things separate, software
rendering becomes much more simple.

Another indicator that supports my confidence is the need to supplement
input-mask information per pixel. With 32-bit RGBA, there is no space
for this information. So we need to append a dedicated input-mask buffer
to the pixel buffer anyway. By keeping the alpha values in a dedicated
buffer, we are consistent with the handling of the input-mask values.

> 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.
BTW, I like the notation RGB+A. Is this your invention?

The framebuffer's representation does not need to be supported by the Qt
API and remains invisible to Qt applications. It is only relevant to the
QPA (platform abstraction).

> 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.

I don't share this concern. Genode's graphics performance is already
quite acceptable despite the use of software rendering. Today,
components like VirtualBox or menu view employ in-band color-space
conversion and dithering. Compared to that, the conversion from RGBA to
RGB+A is trivial and certainly faster.

Second, the output of any non-trivial application is buffered anyway -
simply to avoid artifacts from blitting intermediate drawing states to
the screen.

As the bottom line, I consider the framebuffer organization as a
technicality and doubt that it is worth arguing about it. Should we find
the RGB+A approach limiting sometime down the road, we can learn from
our mistakes and change it.

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