bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Aleksandar Dimitrov]

Hi all,

Runinng in any compositing window manager (this includes Wayland with a
PGTK build of Emacs, but also X without PGTK), the frame parameter
alpha-background is ignored for at least

- fringe bitmaps
- insets drawn with internal-border-width

The resulting visual effect is quite jarring, and makes both of these
difficult to use together with transparency.

Here's a small emacs -Q script to exhibit the problem:

#+begin_src emacs-lisp

;; Turn off scroll bars to make the bugs more visible.
(scroll-bar-mode -1)

;; set transparency & internal border width.
;; Note how the internal border is going to be drawn in a solid white colour
;; and will ignore the alpha value.
(modify-all-frames-parameters '((alpha-background . 50)
                                (internal-border-width . 20)))

(define-fringe-bitmap 'test-bitmap
  (vector (expt 2 15)) nil 16 '(top t))

;; Define a face for the fringe that has a different background colour, to
;; more easily discern the fringe bitmap bug from the internal border bug.
(make-face 'test-face)
(set-face-attribute 'test-face nil :background "pink")

;; Apply a fringe bitmap to all lines in the current buffer. Note how the fringe
;; bitmap is monochrome, but the background colour ignores the global alpha value.
(defun apply-fringe-bitmap ()
  "Apply a fringe bitmap to the current buffer to exhibit the transparency bug."
  (add-text-properties
   (point-min) (point-max)
   '(wrap-prefix
     #(" " 0 1 (display (left-fringe test-bitmap test-face)))
     line-prefix
     #(" " 0 1 (display (left-fringe test-bitmap test-face))))))

(add-hook 'emacs-startup-hook #'apply-fringe-bitmap)

#+end_src


And here's how it looks like: https://aleks.bg/emacs-bug.png
(that's my personal home page, not an image hoster.)

I would expect the white border around the frame to also be transparent,
and the fringe, too.


Aleks

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Eli Zaretskii]

> From: Aleksandar Dimitrov <mail@aleks.bg>
> Date: Wed, 01 May 2024 12:52:58 +0200
> 
> Hi all,
> 
> Runinng in any compositing window manager (this includes Wayland with a
> PGTK build of Emacs, but also X without PGTK), the frame parameter
> alpha-background is ignored for at least
> 
> - fringe bitmaps
> - insets drawn with internal-border-width
> 
> The resulting visual effect is quite jarring, and makes both of these
> difficult to use together with transparency.
> 
> Here's a small emacs -Q script to exhibit the problem:
> 
> #+begin_src emacs-lisp
> 
> ;; Turn off scroll bars to make the bugs more visible.
> (scroll-bar-mode -1)
> 
> ;; set transparency & internal border width.
> ;; Note how the internal border is going to be drawn in a solid white colour
> ;; and will ignore the alpha value.
> (modify-all-frames-parameters '((alpha-background . 50)
>                                 (internal-border-width . 20)))
> 
> (define-fringe-bitmap 'test-bitmap
>   (vector (expt 2 15)) nil 16 '(top t))
> 
> ;; Define a face for the fringe that has a different background colour, to
> ;; more easily discern the fringe bitmap bug from the internal border bug.
> (make-face 'test-face)
> (set-face-attribute 'test-face nil :background "pink")
> 
> ;; Apply a fringe bitmap to all lines in the current buffer. Note how the fringe
> ;; bitmap is monochrome, but the background colour ignores the global alpha value.
> (defun apply-fringe-bitmap ()
>   "Apply a fringe bitmap to the current buffer to exhibit the transparency bug."
>   (add-text-properties
>    (point-min) (point-max)
>    '(wrap-prefix
>      #(" " 0 1 (display (left-fringe test-bitmap test-face)))
>      line-prefix
>      #(" " 0 1 (display (left-fringe test-bitmap test-face))))))
> 
> (add-hook 'emacs-startup-hook #'apply-fringe-bitmap)
> 
> #+end_src
> 
> 
> And here's how it looks like: https://aleks.bg/emacs-bug.png
> (that's my personal home page, not an image hoster.)
> 
> I would expect the white border around the frame to also be transparent,
> and the fringe, too.

Po Lu, any comments or ideas about this?

Thanks.

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Aleksandar Dimitrov <mail@aleks.bg>
>> Date: Wed, 01 May 2024 12:52:58 +0200
>> 
>> Hi all,
>> 
>> Runinng in any compositing window manager (this includes Wayland with a
>> PGTK build of Emacs, but also X without PGTK), the frame parameter
>> alpha-background is ignored for at least
>> 
>> - fringe bitmaps
>> - insets drawn with internal-border-width
>> 
>> The resulting visual effect is quite jarring, and makes both of these
>> difficult to use together with transparency.
>> 
>> Here's a small emacs -Q script to exhibit the problem:
>> 
>> #+begin_src emacs-lisp
>> 
>> ;; Turn off scroll bars to make the bugs more visible.
>> (scroll-bar-mode -1)
>> 
>> ;; set transparency & internal border width.
>> ;; Note how the internal border is going to be drawn in a solid white colour
>> ;; and will ignore the alpha value.
>> (modify-all-frames-parameters '((alpha-background . 50)
>>                                 (internal-border-width . 20)))
>> 
>> (define-fringe-bitmap 'test-bitmap
>>   (vector (expt 2 15)) nil 16 '(top t))
>> 
>> ;; Define a face for the fringe that has a different background colour, to
>> ;; more easily discern the fringe bitmap bug from the internal border bug.
>> (make-face 'test-face)
>> (set-face-attribute 'test-face nil :background "pink")
>> 
>> ;; Apply a fringe bitmap to all lines in the current buffer. Note how the fringe
>> ;; bitmap is monochrome, but the background colour ignores the global alpha value.
>> (defun apply-fringe-bitmap ()
>>   "Apply a fringe bitmap to the current buffer to exhibit the transparency bug."
>>   (add-text-properties
>>    (point-min) (point-max)
>>    '(wrap-prefix
>>      #(" " 0 1 (display (left-fringe test-bitmap test-face)))
>>      line-prefix
>>      #(" " 0 1 (display (left-fringe test-bitmap test-face))))))
>> 
>> (add-hook 'emacs-startup-hook #'apply-fringe-bitmap)
>> 
>> #+end_src
>> 
>> 
>> And here's how it looks like: https://aleks.bg/emacs-bug.png
>> (that's my personal home page, not an image hoster.)
>> 
>> I would expect the white border around the frame to also be transparent,
>> and the fringe, too.
>
> Po Lu, any comments or ideas about this?

This has been previously reported.  As I've stated on those occasions
and numerous others, the internal border is a _border_, a natural
component of a frame's foreground that should not be affected by its
background transparency properties.

As regards fringe bitmaps, they respond to alpha-background on the
XRender builds.  This (untested) patch might extend this to Cairo
builds:

diff --git a/src/xterm.c b/src/xterm.c
index 33ef18d8da5..4fe52bc6bf0 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -6293,7 +6293,7 @@ x_cr_draw_image (struct frame *f, GC gc, cairo_pattern_t *image,
     cairo_rectangle (cr, dest_x, dest_y, width, height);
   else
     {
-      x_set_cr_source_with_gc_background (f, gc, false);
+      x_set_cr_source_with_gc_background (f, gc, true);
       cairo_rectangle (cr, dest_x, dest_y, width, height);
       cairo_fill_preserve (cr);
     }

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Aleksandar Dimitrov]

Hello Po Lu,

> This has been previously reported.  As I've stated on those occasions
> and numerous others, the internal border is a _border_, a natural
> component of a frame's foreground that should not be affected by its
> background transparency properties.

Thanks for your feedback. I didn't find any previous discussions, but I
guess I didn't look hard enough, sorry for that. Is there another way to
create insets in Emacs that does respect transparency settings? Or is
there a way to tweak the frame border's transparency settings that
doesn't also affect the rendered text and other interactive elements?

What I'm looking for is to distance the text somewhat from the edge of
the frame to create some negative space.

> As regards fringe bitmaps, they respond to alpha-background on the
> XRender builds.  This (untested) patch might extend this to Cairo
> builds:

Thanks for the patch. I applied it to the current Emacs (on top of
407b88333) and came to the following conclusion:

When compiling Emacs with --with-toolkit=lucid, the above patch
works. Fringe bitmaps' backgrounds are now transparent.
As before, the internal borders aren't transparent.

When compiling Emacs instead with --with-pgtk, the above patch *does not
work*. However, the internal frame borders *are* transparent there
now. I haven't yet investigated whether that was always the case (and I
simply hadn't compiled Emacs correctly before) or whether that change
came in recently.

I guess the behaviour (whatever it ends up being) should be consistent across toolkits.

Thanks,
Aleks

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Eli Zaretskii]

Ping!  Can we make some further progress with this issue?

> From: Aleksandar Dimitrov <mail@aleks.bg>
> Date: Thu, 16 May 2024 16:26:47 +0200
> CC: eliz@gnu.org,  70697@debbugs.gnu.org
> 
> Hello Po Lu,
> 
> > This has been previously reported.  As I've stated on those occasions
> > and numerous others, the internal border is a _border_, a natural
> > component of a frame's foreground that should not be affected by its
> > background transparency properties.
> 
> Thanks for your feedback. I didn't find any previous discussions, but I
> guess I didn't look hard enough, sorry for that. Is there another way to
> create insets in Emacs that does respect transparency settings? Or is
> there a way to tweak the frame border's transparency settings that
> doesn't also affect the rendered text and other interactive elements?
> 
> What I'm looking for is to distance the text somewhat from the edge of
> the frame to create some negative space.
> 
> > As regards fringe bitmaps, they respond to alpha-background on the
> > XRender builds.  This (untested) patch might extend this to Cairo
> > builds:
> 
> Thanks for the patch. I applied it to the current Emacs (on top of
> 407b88333) and came to the following conclusion:
> 
> When compiling Emacs with --with-toolkit=lucid, the above patch
> works. Fringe bitmaps' backgrounds are now transparent.
> As before, the internal borders aren't transparent.
> 
> When compiling Emacs instead with --with-pgtk, the above patch *does not
> work*. However, the internal frame borders *are* transparent there
> now. I haven't yet investigated whether that was always the case (and I
> simply hadn't compiled Emacs correctly before) or whether that change
> came in recently.
> 
> I guess the behaviour (whatever it ends up being) should be consistent across toolkits.
> 
> Thanks,
> Aleks
> 

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> From: Aleksandar Dimitrov <mail@aleks.bg>
>> Date: Thu, 16 May 2024 16:26:47 +0200
>> CC: eliz@gnu.org,  70697@debbugs.gnu.org

[...]

>> When compiling Emacs with --with-toolkit=lucid, the above patch
>> works. Fringe bitmaps' backgrounds are now transparent.
>> As before, the internal borders aren't transparent.

I suppose you meant to write `--with-x-toolkit=lucid', where
alpha-background is not supported at all, so I'm very much confused as
to why this is so.  Did you really configure Emacs
`--with-toolkit=lucid'?  If you did, you would have been testing a GTK
build.

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Aleksandar Dimitrov]

Po Lu <luangruo@yahoo.com> writes:

>>> From: Aleksandar Dimitrov <mail@aleks.bg>
>>> Date: Thu, 16 May 2024 16:26:47 +0200
>>> CC: eliz@gnu.org,  70697@debbugs.gnu.org
>
> [...]
>
>>> When compiling Emacs with --with-toolkit=lucid, the above patch
>>> works. Fringe bitmaps' backgrounds are now transparent.
>>> As before, the internal borders aren't transparent.
>
> I suppose you meant to write `--with-x-toolkit=lucid', where
> alpha-background is not supported at all, so I'm very much confused as
> to why this is so.  Did you really configure Emacs
> `--with-toolkit=lucid'?  If you did, you would have been testing a GTK
> build.

Welp, I never said I'm good at this :D
I didn't know there was a difference between the --with-toolkit and
--with-x-toolkit options. The former isn't documented in ./configure
--help, it seems. I've opted to only use --with-x-toolkit from now on.

I have conducted some experiments now:
--with-x-toolkit=lucid & your patch:
No transparency support.

--with-x-toolkit=gtk3 & your patch:
Transparency in fringes works.
Internal borders are NOT transparent.
This is identical to my previous test with --with-toolkit=lucid, which
wasn't doing what I expected it to.

--with-pgtk & your patch:
Transparency in fringes DOES NOT work
Internal borders ARE transparent
(also, Emacs is very slow, e.g. when rendering company popups, but
that's unrelated)

All of these tests are conducted with the above Emacs version and on
Wayland.

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Eli Zaretskii]

Ping!  How should we proceed with this issue?

> From: Aleksandar Dimitrov <mail@aleks.bg>
> Cc:  70697@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 03 Jun 2024 22:24:27 +0200
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> >>> From: Aleksandar Dimitrov <mail@aleks.bg>
> >>> Date: Thu, 16 May 2024 16:26:47 +0200
> >>> CC: eliz@gnu.org,  70697@debbugs.gnu.org
> >
> > [...]
> >
> >>> When compiling Emacs with --with-toolkit=lucid, the above patch
> >>> works. Fringe bitmaps' backgrounds are now transparent.
> >>> As before, the internal borders aren't transparent.
> >
> > I suppose you meant to write `--with-x-toolkit=lucid', where
> > alpha-background is not supported at all, so I'm very much confused as
> > to why this is so.  Did you really configure Emacs
> > `--with-toolkit=lucid'?  If you did, you would have been testing a GTK
> > build.
> 
> Welp, I never said I'm good at this :D
> I didn't know there was a difference between the --with-toolkit and
> --with-x-toolkit options. The former isn't documented in ./configure
> --help, it seems. I've opted to only use --with-x-toolkit from now on.
> 
> I have conducted some experiments now:
> --with-x-toolkit=lucid & your patch:
> No transparency support.
> 
> --with-x-toolkit=gtk3 & your patch:
> Transparency in fringes works.
> Internal borders are NOT transparent.
> This is identical to my previous test with --with-toolkit=lucid, which
> wasn't doing what I expected it to.
> 
> --with-pgtk & your patch:
> Transparency in fringes DOES NOT work
> Internal borders ARE transparent
> (also, Emacs is very slow, e.g. when rendering company popups, but
> that's unrelated)
> 
> All of these tests are conducted with the above Emacs version and on
> Wayland.
> 

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  How should we proceed with this issue?
>
>> From: Aleksandar Dimitrov <mail@aleks.bg>

Alexander, is there something suspicious as to your mail host that is
prompting mine to discard your responses?  They aren't even classified
Bulk Mail, just quietly disposed of.

>> Welp, I never said I'm good at this :D
>> I didn't know there was a difference between the --with-toolkit and
>> --with-x-toolkit options. The former isn't documented in ./configure
>> --help, it seems. I've opted to only use --with-x-toolkit from now on.
>> 
>> I have conducted some experiments now:
>> --with-x-toolkit=lucid & your patch:
>> No transparency support.
>> 
>> --with-x-toolkit=gtk3 & your patch:
>> Transparency in fringes works.
>> Internal borders are NOT transparent.
>> This is identical to my previous test with --with-toolkit=lucid, which
>> wasn't doing what I expected it to.
>> 
>> --with-pgtk & your patch:
>> Transparency in fringes DOES NOT work
>> Internal borders ARE transparent
>> (also, Emacs is very slow, e.g. when rendering company popups, but
>> that's unrelated)
>> 
>> All of these tests are conducted with the above Emacs version and on
>> Wayland.

Yes, thanks.  Please try the patch attached: its effect should be to
homogenize PGTK's display with the X port's.

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 49b7ea406f8..e379ed33c01 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -3594,20 +3594,7 @@ pgtk_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
   pgtk_clip_to_row (w, row, ANY_AREA, cr);
 
   if (p->bx >= 0 && !p->overlay_p)
-    {
-      /* In case the same realized face is used for fringes and for
-         something displayed in the text (e.g. face `region' on
-         mono-displays, the fill style may have been changed to
-         FillSolid in pgtk_draw_glyph_string_background.  */
-      if (face->stipple)
-	fill_background_by_face (f, face, p->bx, p->by, p->nx, p->ny);
-      else
-	{
-	  pgtk_set_cr_source_with_color (f, face->background, true);
-	  cairo_rectangle (cr, p->bx, p->by, p->nx, p->ny);
-	  cairo_fill (cr);
-	}
-    }
+    fill_background_by_face (f, face, p->bx, p->by, p->nx, p->ny);
 
   if (p->which
       && p->which < max_fringe_bmp
@@ -5014,14 +5001,16 @@ pgtk_clear_under_internal_border (struct frame *f)
 
       if (face)
 	{
-	  fill_background_by_face (f, face, 0, margin, width, border);
-	  fill_background_by_face (f, face, 0, 0, border, height);
-	  fill_background_by_face (f, face, width - border, 0, border,
-				   height);
-	  fill_background_by_face (f, face, 0, (height
-						- bottom_margin
-						- border),
-				   width, border);
+	  pgtk_fill_rectangle (f, face->foreground, 0, margin, width,
+			       border, false);
+	  pgtk_fill_rectangle (f, face->foreground, 0, 0, border, height,
+			       false);
+	  pgtk_fill_rectangle (f, face->foreground, width - border, 0,
+			       border, height, false);
+	  pgtk_fill_rectangle (f, face->foreground, 0, (height
+							- bottom_margin
+							- border),
+			       width, border, false);
 	}
       else
 	{

bug#70697: 30.0.50; Frame parameter alpha-background is ignored for fringe bitmaps & internal borders

[Eli Zaretskii]

Ping! Aleksandar, can you please try Po Lu's patch and report back?

> From: Po Lu <luangruo@yahoo.com>
> Cc: Aleksandar Dimitrov <mail@aleks.bg>,  70697@debbugs.gnu.org
> Date: Sat, 15 Jun 2024 19:20:21 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Ping!  How should we proceed with this issue?
> >
> >> From: Aleksandar Dimitrov <mail@aleks.bg>
> 
> Alexander, is there something suspicious as to your mail host that is
> prompting mine to discard your responses?  They aren't even classified
> Bulk Mail, just quietly disposed of.
> 
> >> Welp, I never said I'm good at this :D
> >> I didn't know there was a difference between the --with-toolkit and
> >> --with-x-toolkit options. The former isn't documented in ./configure
> >> --help, it seems. I've opted to only use --with-x-toolkit from now on.
> >> 
> >> I have conducted some experiments now:
> >> --with-x-toolkit=lucid & your patch:
> >> No transparency support.
> >> 
> >> --with-x-toolkit=gtk3 & your patch:
> >> Transparency in fringes works.
> >> Internal borders are NOT transparent.
> >> This is identical to my previous test with --with-toolkit=lucid, which
> >> wasn't doing what I expected it to.
> >> 
> >> --with-pgtk & your patch:
> >> Transparency in fringes DOES NOT work
> >> Internal borders ARE transparent
> >> (also, Emacs is very slow, e.g. when rendering company popups, but
> >> that's unrelated)
> >> 
> >> All of these tests are conducted with the above Emacs version and on
> >> Wayland.
> 
> Yes, thanks.  Please try the patch attached: its effect should be to
> homogenize PGTK's display with the X port's.
> 
> diff --git a/src/pgtkterm.c b/src/pgtkterm.c
> index 49b7ea406f8..e379ed33c01 100644
> --- a/src/pgtkterm.c
> +++ b/src/pgtkterm.c
> @@ -3594,20 +3594,7 @@ pgtk_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
>    pgtk_clip_to_row (w, row, ANY_AREA, cr);
>  
>    if (p->bx >= 0 && !p->overlay_p)
> -    {
> -      /* In case the same realized face is used for fringes and for
> -         something displayed in the text (e.g. face `region' on
> -         mono-displays, the fill style may have been changed to
> -         FillSolid in pgtk_draw_glyph_string_background.  */
> -      if (face->stipple)
> -	fill_background_by_face (f, face, p->bx, p->by, p->nx, p->ny);
> -      else
> -	{
> -	  pgtk_set_cr_source_with_color (f, face->background, true);
> -	  cairo_rectangle (cr, p->bx, p->by, p->nx, p->ny);
> -	  cairo_fill (cr);
> -	}
> -    }
> +    fill_background_by_face (f, face, p->bx, p->by, p->nx, p->ny);
>  
>    if (p->which
>        && p->which < max_fringe_bmp
> @@ -5014,14 +5001,16 @@ pgtk_clear_under_internal_border (struct frame *f)
>  
>        if (face)
>  	{
> -	  fill_background_by_face (f, face, 0, margin, width, border);
> -	  fill_background_by_face (f, face, 0, 0, border, height);
> -	  fill_background_by_face (f, face, width - border, 0, border,
> -				   height);
> -	  fill_background_by_face (f, face, 0, (height
> -						- bottom_margin
> -						- border),
> -				   width, border);
> +	  pgtk_fill_rectangle (f, face->foreground, 0, margin, width,
> +			       border, false);
> +	  pgtk_fill_rectangle (f, face->foreground, 0, 0, border, height,
> +			       false);
> +	  pgtk_fill_rectangle (f, face->foreground, width - border, 0,
> +			       border, height, false);
> +	  pgtk_fill_rectangle (f, face->foreground, 0, (height
> +							- bottom_margin
> +							- border),
> +			       width, border, false);
>  	}
>        else
>  	{
>