From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Filippo Argiolas Newsgroups: gmane.emacs.devel Subject: Re: Face transparency attribute Date: Fri, 3 May 2024 09:01:15 +0200 Message-ID: References: <87sf2v8lu4.fsf@nixos.mail-host-address-is-not-set> <875xzrw1te.fsf@yahoo.com> <87v85k1myr.fsf@posteo.de> <87sf0nr6mj.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40178"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Nate Sandy , =?UTF-8?Q?Sebastian_W=C3=A5linder?= , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 03 09:02:11 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s2mvr-000ADt-8f for ged-emacs-devel@m.gmane-mx.org; Fri, 03 May 2024 09:02:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2mvG-0001xu-FD; Fri, 03 May 2024 03:01:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2mvD-0001t3-GZ for emacs-devel@gnu.org; Fri, 03 May 2024 03:01:32 -0400 Original-Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s2mvB-0006LJ-Fj for emacs-devel@gnu.org; Fri, 03 May 2024 03:01:31 -0400 Original-Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5dca1efad59so6479325a12.2 for ; Fri, 03 May 2024 00:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714719686; x=1715324486; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CPVDOaA95trxzaq43dVX6v1E6IhMBEWoNvgL144lInk=; b=KSlxff0HXN+Ojvf76VhsSFuqFdXTX7q9rEzplL6YsZqWE+wbcIvOJVzYzslNNxjt7h cHZQnsEc+yE+ZIe0pQXQOVlCkQZrrFsFsiWaj6Tb5eUCuL+0j4ZQ0q9OSP6cc4LkpmgJ NtkvLGfsCBFaYj+9G/Wth8rCeKEq/uwjD+jCMfnMoRDATbo5g82iMOOWCuN+IlnniAGP Z3lt81celnDMogNH7HUCD1SUHBKqlkY2s6hQ5N/Hj6C+skOhE5GlcGWDTFLRlCqf83Hi bpwq7gyUS7sma2EFwQirtuZKU8X6A59IyKJHpyYajoVJmejrayY5z0GI1FfkYr3Csutz Q0Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714719686; x=1715324486; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CPVDOaA95trxzaq43dVX6v1E6IhMBEWoNvgL144lInk=; b=Ffq+LDV4ArR51ASmESwu52plvfuvnW+Wx1W6pT92MBgQwlxEpANY2S26GZyqBizT8I UechBgaFe/9pu3jtKhEAetP6y5kyo0/j8E/k4OW8glKD+hYiNrR8OJ2VX4efAyt/p9DD tAF/e8GaYdiKnMWCmyFmQ6P9ARpSa+M3ZYo/+Qgyn+4sG/p2MyglCpQN1F0VLePh2ep5 xMJLEdoI1mK3FBaP7I1JtUzxbne4nvm7BBuvicm0T4XeU/c+tWw2fMTqJh9+gEhVo6T0 FeTwak1qi3453J6iw4TtHX2duSUaFQrqYVEKsj8XaZWpkIyV0QH/2vR0cHRwr1XW/UcM aO3A== X-Forwarded-Encrypted: i=1; AJvYcCUrMi5BtKjFcgnCC6aK0lqLQI/yc9x7u2UzjMDqgxMs6TdgMNz5BBzE+Jgw7wnToshp6qu3ovbAOA5nbpbD/tTRsv9J X-Gm-Message-State: AOJu0YylinbpbAvrZHCrXH/WtxL6bJv2xXgadPXza35qk2PSngdGy8of WGgZewhqfz08ghJoca+JGh0e4Ndoczp7idEjX8EWbE7hpAIEjUPF8APAqrttwxgbh0SUYOREoTT 1K+JwcDoS30Bi0fQEErQo7C1p8qQ= X-Google-Smtp-Source: AGHT+IE+N2y2BmuNL0H+zBoPVj6bSUKBZ647iCp49KKkh17R3bRVaaYA+hOMifo4MTz3Xk4HG/cN6jTwPmxFsHW298o= X-Received: by 2002:a17:90b:f8c:b0:2a2:f284:5196 with SMTP id ft12-20020a17090b0f8c00b002a2f2845196mr1106982pjb.45.1714719686378; Fri, 03 May 2024 00:01:26 -0700 (PDT) In-Reply-To: <87sf0nr6mj.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::532; envelope-from=filippo.argiolas@gmail.com; helo=mail-pg1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318641 Archived-At: A bit late but I agree that we should have a separate attribute for this. My use case would be to shade inactive code regions like I do in [1]. Right now I'm using a super hacky method that hooks into fontification and adds an overlay for each symbol in the buffer with a shaded foreground color. With Nate's patch I would still have the very same problem. With an attribute I could just set a single overlay over the whole inactive region and not mess with fontification. Is anyone still working on this? Nate? Cheers, Filippo 1. https://github.com/fargiolas/clangd-inactive-regions.el On Mon, Mar 18, 2024 at 2:51=E2=80=AFPM Po Lu wrote: > > Nate Sandy writes: > > > Po Lu 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, whic= h > > 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` to= o? > > > > 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. >