emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sv: Sv: Sv: Support for background transparency


From: Po Lu
Subject: Re: Sv: Sv: Sv: Support for background transparency
Date: Fri, 21 Jan 2022 08:59:01 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Håkon Flatval <hkon20@hotmail.com> writes:

> I now run a check on the bit depth of the visual in the
> x_set_cr_source_with_gc_background function. I'm not too happy about
> this solution, as it involves two more calls to the X API, but perhaps
> it is acceptable.

You could just check dpyinfo->n_planes, which should suffice (and avoid
the calls to `XGetVisualInfo').

> +  if (f->alpha_background < 1.0 && depth == 32) {
> +    cairo_set_source_rgba (FRAME_CR_CONTEXT (f), color.red / 65535.0,
> +                           color.green / 65535.0, color.blue / 65535.0, 
> f->alpha_background);
> +
> +    cairo_set_operator (FRAME_CR_CONTEXT (f), CAIRO_OPERATOR_SOURCE);
> +  } else {
> +    cairo_set_source_rgb (FRAME_CR_CONTEXT (f), color.red / 65535.0,
> +                          color.green / 65535.0, color.blue / 65535.0);
> +  }

This coding style is not what we use in Emacs.  You can look at the
surrounding code and
https://www.gnu.org/prep/standards/standards.html#Formatting for more
details on how such braces should be formatted.

> I have primarily considered GTK and Cairo when implementing
> this. Support for other build configurations do not work currently.

Would you mind if I implemented that support instead?

> It will require additional treatment of e.g. the LUCID libs. I have
> looked a bit on such builds on the side, but currently have not shaped
> a plan to finish it.

The Xt builds are unlikely to ever work with this, since I couldn't find
a way to create the shell widget with a 32 bit visual, and we can only
draw into a child window (which isn't composited) on those builds
anyway.  But I do want the non-Cairo GTK and no-toolkit builds to work.

> The preprocessor statements are to ensure nothing else is screwed up
> when using 32-bit visuals.

Which preprocessor statements are you referring to?

Aside from that, I'm happy now.  Thanks for working on this often
requested (and thus important) feature.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]