Library Isolation

[Nobody III]

You're probably right. I probably overestimated the overhead of the RGBA ->
RGB+A -> RGBA/ARGB conversion. And yes, I invented the RGB+A notation.

On Fri, Mar 16, 2018 at 2:25 AM, Norman Feske <norman.feske at ...1...>
wrote:

> 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
>
> ------------------------------------------------------------
> ------------------
> 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/20180316/0e42384b/attachment.html>