Re: Face transparency attribute

[Po Lu <luangruo@yahoo.com>]

Nate Sandy <nsan@posteo.de> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Neither approach is easy or exceptionally challenging, so interested
>> individuals are invited to chose whichever they should find more to
>> their liking.
>
> Hi Po,
>
> I have written a patch for this for the pgtk backend and went with the
> first route - supporting an alpha channel in face colors. I figured it's
> nicer since we get alpha channels for all other text decorations as
> well.
>
> The way it works is that when painting a background color (one which
> respects alpha-background), we instead compose it with the frame
> background color via a re-implementation of CAIRO_OPERATOR_OVER. I
> didn't find a way to do this with cairo itself without painting the
> surface inbetween.
>
> I also made sure that this patch integrates with alpha-background, which
> is also my primary use case - fully hiding faces which don't respect
> alpha-background.
>
> The only syntax supported for transparency is gtk_parse_rgba's
> `rgba(255,255,255,1.0)`. Maybe we would want support for `#ff00ff00` too?
>
> One interesting quirk is that when changing the opacity of the `default`
> face to less than 1, the whole background is fully transparent again. I
> am not sure whether this is a fault in my code or because of some extra
> logic regarding the `default` face.
>
> Attached are a screenshot and the patch. I'd very much appreciate
> feedback. If necessary I could also try to implement this for X and/or
> terminals, however I don't have access to other platforms.

I'm not happy with this approach, since it defines the alpha value as an
integral component of a face's foreground and background colors, rather
than an attribute (or attributes) the face merging process can manage
independently to prevent alpha values from being transferred between
faces against the user's wishes, and more broadly to enable specifying
alpha values separately from face colors, which there is plenty of
reason for users to replace that might not apply to transparency in
identical circumstances.

Furthermore, the transparency implemented in this patch is specified
with premultiplied values--premultiplied alpha is more efficient on free
systems, but admits of invalid color values whose behavior is undefined
across all the systems and toolkits we support.  It's already too easy
for Emacs users to shoot themselves in the foot, and muddling the waters
with the potential for invalid color definitions would be a step in the
wrong direction, in my humble estimation, so I would prefer an
implementation that exposes straight alpha values to users, converting
between those and the suitable alpha format for the toolkit at display
time.