unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: "Håkon Flatval" <hkon20@hotmail.com>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Sv: Sv: Sv: Support for background transparency
Date: Fri, 21 Jan 2022 08:59:01 +0800	[thread overview]
Message-ID: <874k5x29be.fsf@yahoo.com> (raw)
In-Reply-To: <PRAP251MB0688D5598FB165C53AD95A81CF5A9@PRAP251MB0688.EURP251.PROD.OUTLOOK.COM> ("Håkon Flatval"'s message of "Thu, 20 Jan 2022 19:52:33 +0000")

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	other threads:[~2022-01-21  0:59 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 19:45 Support for background transparency Håkon Flatval
2021-11-04 20:06 ` Eli Zaretskii
2021-11-04 20:17 ` Lars Ingebrigtsen
2021-11-27 23:01   ` Håkon Flatval
2021-11-28  0:35     ` Sv: " arthur miller
2021-11-28 13:32       ` Lars Ingebrigtsen
2021-11-28 16:04         ` Arthur Miller
2021-11-28 20:33           ` Håkon Flatval
2021-11-29  2:56             ` Arthur Miller
2021-11-28  7:41     ` Eli Zaretskii
2021-11-28  7:47       ` Po Lu
2021-11-28  8:27         ` Eli Zaretskii
2021-12-01 18:54       ` Sv: " Håkon Flatval
2021-12-09 17:13         ` Håkon Flatval
2021-12-10  0:40           ` Lars Ingebrigtsen
2022-01-19 17:26             ` Sv: " Håkon Flatval
2022-01-20  0:52               ` Po Lu
2022-01-20 19:52                 ` Sv: " Håkon Flatval
2022-01-21  0:59                   ` Po Lu [this message]
2022-01-23 13:48                     ` Håkon Flatval
2022-01-24  0:11                       ` Po Lu
2022-01-25 17:53                         ` Håkon Flatval
2022-01-26  1:00                           ` Po Lu
2022-01-24 10:22                       ` Po Lu
2022-01-25 19:47                         ` Håkon Flatval
2022-01-25 19:37                           ` Robert Pluim
2022-01-26 18:16                             ` Håkon Flatval
2022-01-26  1:05                           ` Po Lu
2022-01-26 11:11                             ` Robert Pluim
2022-01-26 18:34                             ` Håkon Flatval
2022-01-27  1:00                               ` Po Lu
2022-01-29  0:01                                 ` Håkon Flatval
2022-01-29  1:08                                   ` Po Lu
2022-01-20  9:12               ` Robert Pluim
2022-01-23 21:43                 ` Håkon Flatval
2022-01-24  9:14                   ` Robert Pluim
2022-01-25 20:00                     ` Håkon Flatval
2022-01-25 19:31                       ` Robert Pluim
2022-01-29 10:26                         ` Po Lu
2022-01-29 15:17                           ` Håkon Flatval
2022-01-30  0:53                             ` Po Lu
2021-11-28 13:41     ` Lars Ingebrigtsen
2021-11-28 15:05       ` Sv: " Håkon Flatval
2021-11-28 16:07         ` Gregor Zattler
2021-11-28 16:32         ` Lars Ingebrigtsen
2021-11-28 18:10     ` Jean Louis
2021-11-28 18:44       ` Sv: " Håkon Flatval

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874k5x29be.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=emacs-devel@gnu.org \
    --cc=hkon20@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).