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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70697 in the body.
You can then email your comments to 70697 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aleksandar Dimitrov <mail <at> aleks.bg>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Frame parameter alpha-background is ignored for fringe
 bitmaps & internal borders
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.


Aleks

Message #8 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aleksandar Dimitrov <mail <at> aleks.bg>, Po Lu <luangruo <at> yahoo.com>
Cc: 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50;
 Frame parameter alpha-background is ignored for fringe bitmaps &
 internal borders
Date: Thu, 09 May 2024 10:46:46 +0300

> From: Aleksandar Dimitrov <mail <at> 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.

Message #11 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aleksandar Dimitrov <mail <at> aleks.bg>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Thu, 09 May 2024 16:03:20 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Aleksandar Dimitrov <mail <at> 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);
     }

Message #14 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Aleksandar Dimitrov <mail <at> aleks.bg>
To: luangruo <at> yahoo.com
Cc: eliz <at> gnu.org, 70697 <at> debbugs.gnu.org
Subject: bug#70697: 30.0.50; Frame parameter alpha-background is ignored for
 fringe bitmaps & internal borders
Date: Thu, 16 May 2024 16:26:47 +0200

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

Message #17 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aleksandar Dimitrov <mail <at> aleks.bg>
Cc: luangruo <at> yahoo.com, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50;
 Frame parameter alpha-background is ignored for
 fringe bitmaps & internal borders
Date: Sat, 01 Jun 2024 17:03:38 +0300

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

> From: Aleksandar Dimitrov <mail <at> aleks.bg>
> Date: Thu, 16 May 2024 16:26:47 +0200
> CC: eliz <at> gnu.org,  70697 <at> 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
> 

Message #20 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aleksandar Dimitrov <mail <at> aleks.bg>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Sat, 01 Jun 2024 22:07:19 +0800

>> From: Aleksandar Dimitrov <mail <at> aleks.bg>
>> Date: Thu, 16 May 2024 16:26:47 +0200
>> CC: eliz <at> gnu.org,  70697 <at> 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.

Message #23 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Aleksandar Dimitrov <mail <at> aleks.bg>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Mon, 03 Jun 2024 22:24:27 +0200

Po Lu <luangruo <at> yahoo.com> writes:

>>> From: Aleksandar Dimitrov <mail <at> aleks.bg>
>>> Date: Thu, 16 May 2024 16:26:47 +0200
>>> CC: eliz <at> gnu.org,  70697 <at> 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.

Message #26 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com, Aleksandar Dimitrov <mail <at> aleks.bg>
Cc: 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Sat, 15 Jun 2024 11:11:20 +0300

Ping!  How should we proceed with this issue?

> From: Aleksandar Dimitrov <mail <at> aleks.bg>
> Cc:  70697 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Mon, 03 Jun 2024 22:24:27 +0200
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> >>> From: Aleksandar Dimitrov <mail <at> aleks.bg>
> >>> Date: Thu, 16 May 2024 16:26:47 +0200
> >>> CC: eliz <at> gnu.org,  70697 <at> 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.
> 

Message #29 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aleksandar Dimitrov <mail <at> aleks.bg>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Sat, 15 Jun 2024 19:20:21 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping!  How should we proceed with this issue?
>
>> From: Aleksandar Dimitrov <mail <at> 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
 	{

Message #32 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mail <at> aleks.bg, Po Lu <luangruo <at> yahoo.com>
Cc: 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Thu, 27 Jun 2024 10:41:29 +0300

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Aleksandar Dimitrov <mail <at> aleks.bg>,  70697 <at> debbugs.gnu.org
> Date: Sat, 15 Jun 2024 19:20:21 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ping!  How should we proceed with this issue?
> >
> >> From: Aleksandar Dimitrov <mail <at> 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
>  	{
> 

Message #35 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Aleksandar Dimitrov <mail <at> aleks.bg>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Mon, 08 Jul 2024 19:08:53 +0200

Hi Eli, Po Lu,

sorry for taking a while to get back to you, I've had a busy week or
two.

I've tried out Po Lu's patch. Now:

- the bug with the fringe is fixed in both pgtk and gtk3
- insets are not opaque anymore in pgtk
- insets are *black* and opaque with the minimal repro I posted in the beginning of
  this thread --with-pgtk
- insets are *white* and opaque --with-x-toolkit=gtk3 (again with the minimal repro)

I'm not sure why that is, or whether that's a problem.

>> 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.

Dunno, maybe your mail host doesn't like Emacs from Eastern Europe? I've
not had that problem anywhere else. My mail provider is actually
Australian, though. Only the domain is .bg

Thanks for all your work!

Aleks

Message #38 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Aleksandar Dimitrov <mail <at> aleks.bg>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Tue, 09 Jul 2024 14:12:24 +0800

Aleksandar Dimitrov <mail <at> aleks.bg> writes:

> Hi Eli, Po Lu,
>
> sorry for taking a while to get back to you, I've had a busy week or
> two.
>
> I've tried out Po Lu's patch. Now:
>
> - the bug with the fringe is fixed in both pgtk and gtk3

Thanks, this portion of the patch has been installed in emacs-30.

> - insets are not opaque anymore in pgtk
> - insets are *black* and opaque with the minimal repro I posted in the beginning of
>   this thread --with-pgtk
> - insets are *white* and opaque --with-x-toolkit=gtk3 (again with the minimal repro)
>
> I'm not sure why that is, or whether that's a problem.

I'll continue pursuing this matter.

Message #41 received at 70697 <at> debbugs.gnu.org (full text, mbox):

From: Aleksandar Dimitrov <mail <at> aleks.bg>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70697 <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Tue, 16 Jul 2024 10:11:57 +0200

Hi Po Lu,

>> - the bug with the fringe is fixed in both pgtk and gtk3
>
> Thanks, this portion of the patch has been installed in emacs-30.

Thank you :)

>> - insets are not opaque anymore in pgtk
>> - insets are *black* and opaque with the minimal repro I posted in the beginning of
>>   this thread --with-pgtk
>> - insets are *white* and opaque --with-x-toolkit=gtk3 (again with
>> the minimal repro)
>>
>> I'm not sure why that is, or whether that's a problem.
>
> I'll continue pursuing this matter.

OK, thanks. Since that's not really part of the original problem, I'd
consider the matter resolved. I'll think about making a feature request
in the future to create transparent insets. Thanks for your work on Emacs'
graphical frontends!

Cheers,
Aleks

Message #46 received at 70697-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Aleksandar Dimitrov <mail <at> aleks.bg>,
 70697-done <at> debbugs.gnu.org
Subject: Re: bug#70697: 30.0.50; Frame parameter alpha-background is ignored
 for fringe bitmaps & internal borders
Date: Fri, 28 Feb 2025 18:36:25 -0800

Po Lu <luangruo <at> yahoo.com> writes:

> Aleksandar Dimitrov <mail <at> aleks.bg> writes:
>
>> Hi Eli, Po Lu,
>>
>> sorry for taking a while to get back to you, I've had a busy week or
>> two.
>>
>> I've tried out Po Lu's patch. Now:
>>
>> - the bug with the fringe is fixed in both pgtk and gtk3
>
> Thanks, this portion of the patch has been installed in emacs-30.

I'm therefore closing this bug report.

>> - insets are not opaque anymore in pgtk
>> - insets are *black* and opaque with the minimal repro I posted in the beginning of
>>   this thread --with-pgtk
>> - insets are *white* and opaque --with-x-toolkit=gtk3 (again with the minimal repro)
>>
>> I'm not sure why that is, or whether that's a problem.
>
> I'll continue pursuing this matter.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.