bug#64923: 29.1; white background glitch with new graphical frames

bug#64923: 29.1; white background glitch with new graphical frames

[Thiago Melo]

Under the conditions specified below, new graphical frames are
completely white until a redrawing is forced (usually by resizing the
frame):

Emacs built with:

- No toolkit OR Lucid (--with-x-toolkit=no OR --with-x-toolkit=lucid)
- Cairo (--with-cairo)
- Double buffering (--with-xdbe)

Plus:

- Without an X window manager OR using TinyWM
- No toolkit builds: when scrollbar is disabled before creating the frame
- Lucid builds: when scrollbar AND menubar are disabled before
creating the frame

Affects `emacs -Q'.  Tested on Debian GNU/Linux 12.1 (Bookworm).

Issue started happening since commit
e361d0d7e5d3db8575d5d8673012aa4d7448ee54 (Tue Mar 1 20:15:02 2022
+0800, "Add PropertyChangeMask to the standard event set").  Found via
bisect.

Also, out of all (non-toy) window managers I've tested so far
(awesome, dwm, fluxbox, fvwm2, herbstluftwm, i3, twm, xfwm4; all from
stock Debian repository and with default config), only awesome wm
shows direct signs of this issue, and only when set to use floating
windows.  However, in this condition, new frames have a white
background only in areas without text, regardless of theme (more
evident with a dark theme, eg: `M-x load-theme' -> `wombat').

I suspect this issue might be related to bug#64846 as well.

bug#64923: 29.1; white background glitch with new graphical frames

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

Thiago Melo <tmdmelo@gmail.com> writes:

> Under the conditions specified below, new graphical frames are
> completely white until a redrawing is forced (usually by resizing the
> frame):
>
> Emacs built with:
>
> - No toolkit OR Lucid (--with-x-toolkit=no OR --with-x-toolkit=lucid)
> - Cairo (--with-cairo)
> - Double buffering (--with-xdbe)
>
> Plus:
>
> - Without an X window manager OR using TinyWM
> - No toolkit builds: when scrollbar is disabled before creating the frame
> - Lucid builds: when scrollbar AND menubar are disabled before
> creating the frame
>
> Affects `emacs -Q'.  Tested on Debian GNU/Linux 12.1 (Bookworm).
>
> Issue started happening since commit
> e361d0d7e5d3db8575d5d8673012aa4d7448ee54 (Tue Mar 1 20:15:02 2022
> +0800, "Add PropertyChangeMask to the standard event set").  Found via
> bisect.

Perhaps a change to a window property temporarily misleads Emacs into
believing that the frame is iconified or otherwise invisible.  Does your
problem remain with the following change to xterm.c?

diff --git a/src/xterm.c b/src/xterm.c
index 61b9d972e57..466b86fe32a 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -19396,6 +19396,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 
       f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
       if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state
+	  && 0
 	  /* This should never happen with embedded windows.  */
 	  && !FRAME_X_EMBEDDED_P (f))
 	{
@@ -19441,6 +19442,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	}
 
       if (f && event->xproperty.atom == dpyinfo->Xatom_wm_state
+	  && 0
 	  && !FRAME_X_EMBEDDED_P (f) && !FRAME_PARENT_FRAME (f))
 	/* Handle WM_STATE.  We use this to clear the iconified flag
 	   on a frame if it is set.

bug#64923: 29.1; white background glitch with new graphical frames

[Thiago Melo]

On Sat, Jul 29, 2023 at 12:20 AM Po Lu <luangruo@yahoo.com> wrote:
> Perhaps a change to a window property temporarily misleads Emacs into
> believing that the frame is iconified or otherwise invisible.  Does your
> problem remain with the following change to xterm.c?
>
> [...]

The problem remains, unfortunately.

I'm testing it against the emacs-29 branch, by the way.

bug#64923: 29.1; white background glitch with new graphical frames

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

Thiago Melo <tmdmelo@gmail.com> writes:

> On Sat, Jul 29, 2023 at 12:20 AM Po Lu <luangruo@yahoo.com> wrote:
>> Perhaps a change to a window property temporarily misleads Emacs into
>> believing that the frame is iconified or otherwise invisible.  Does your
>> problem remain with the following change to xterm.c?
>>
>> [...]
>
> The problem remains, unfortunately.
>
> I'm testing it against the emacs-29 branch, by the way.

That's very unusual.  Let's try ignoring PropertyNotify events
altogether: if this doesn't work, it's not a problem with Emacs's
immediate treatment of PropertyNotify events.

diff --git a/src/xterm.c b/src/xterm.c
index 61b9d972e57..0ccfc55c96f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -19336,6 +19336,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       break;
 
     case PropertyNotify:
+      goto OTHER;
+
       if (x_dnd_in_progress && x_dnd_use_toplevels
 	  && dpyinfo == FRAME_DISPLAY_INFO (x_dnd_frame)
 	  && event->xproperty.atom == dpyinfo->Xatom_wm_state)

By the way, does a frame exhibiting this problem update completely
without being resized if you run:

  (redraw-display)
  (redisplay)

?

bug#64923: 29.1; white background glitch with new graphical frames

[Thiago Melo]

Po Lu, before I address your questions: I investigated the matter
further and tested things more thoroughly.  The actual commit related
to the issue of new frames being completely blank was an earlier one:
a190b4cfd8b6f42a91678ac7292e1cceccd168e7 (Tue Apr 27 09:53:42 2021
+0200
"Major rewrite of adjust_frame_size").  Big stuff, and before Emacs
28.1.  I'm putting the original author, Martin, in CC.  He might have
some ideas.

So, most conditions I mentioned before still apply:

- Emacs built with Cairo.
- Emacs built without toolkit or Lucid.
- Running without a window manager (or almost, by using TinyWM).
- Scrollbars must be disabled. Must also disable menubar for Lucid.

However, I noticed one difference: without double buffering, new
frames are still completely empty, but they take the theme background
color.  When compiled with double buffering, new frames are completely
white, as I reported before.

Now, the issue of new frames having a white background in regions
without text, regardless of theme, AND while running a window manager
(Awesome WM, in particular), this was the one that started happening
since commit e361d0d7e5d3db8575d5d8673012aa4d7448ee54.

Still, we can see how these two issues are connected, considering that
they are triggered by a set of common conditions, plus the fact that
the Awesome WM related issue requires Emacs compiled with double
buffering.

Actually, I found one situation where I can create new frames with
white-background-only-in-regions-without-text, regardless of window
manager: by first creating the frame while not running a window
manager, and then starting one.


Now, your questions:

On Sat, Jul 29, 2023 at 11:18 AM Po Lu <luangruo@yahoo.com> wrote:
> That's very unusual.  Let's try ignoring PropertyNotify events
> altogether: if this doesn't work, it's not a problem with Emacs's
> immediate treatment of PropertyNotify events.
>
> diff --git a/src/xterm.c b/src/xterm.c
> [...]

This patch didn't work either.

> By the way, does a frame exhibiting this problem update completely
> without being resized if you run:
>
>   (redraw-display)
>   (redisplay)
>
> ?

- redraw-display : With a window manager (even tinywm), the glitched
frames update completely.  Without a window manager, nothing happens
(unless I start and close a window manager after creating the frame).

- redisplay : does nothing in either case.


Sorry about mixing up things regarding which commit did what in my
initial report.

bug#64923: 29.1; white background glitch with new graphical frames

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

Thiago Melo <tmdmelo@gmail.com> writes:

> - redraw-display : With a window manager (even tinywm), the glitched
> frames update completely.  Without a window manager, nothing happens
> (unless I start and close a window manager after creating the frame).
>
> - redisplay : does nothing in either case.
>
>
> Sorry about mixing up things regarding which commit did what in my
> initial report.

Does this fix both your problems?

diff --git a/src/xfns.c b/src/xfns.c
index 55bcfb8e20e..222e24f1326 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5393,6 +5393,17 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
   gui_default_parameter (f, parms, Qfullscreen, Qnil,
                          "fullscreen", "Fullscreen", RES_TYPE_SYMBOL);
 
+#ifdef USE_CAIRO
+  /* Set the initial size of the Cairo surface to the frame's current
+     width and height.  If the window manager doesn't resize the new
+     frame after it's first mapped, Emacs will create a surface with
+     empty dimensions in response to to the initial exposure event,
+     which will persist until the next time it's resized.
+     (bug#64923) */
+  x_cr_update_surface_desired_size (f, FRAME_PIXEL_WIDTH (f),
+				    FRAME_PIXEL_HEIGHT (f));
+#endif /* USE_CAIRO */
+
   /* Make the window appear on the frame and enable display, unless
      the caller says not to.  However, with explicit parent, Emacs
      cannot control visibility, so don't try.  */

If the window manager doesn't modify the dimensions of the frame's inner
window or send a synthetic configure event at that time, Emacs will
never initialize the ``desired size'' of Cairo surfaces created for that
frame's drawable, and as a result a surface of size 0 will be created at
the time of the next drawing operation.  This situation transpires when
the window manager is extremely simple, or when no window manager is
running at all.

Because the surface's dimensions are empty, Cairo will not draw at all.
This unfortunate situation continues until the next time the window is
resized and handle_one_xevent updates desired size to the dimensions
specified within the resulting ConfigureNotify event.

Eli, is this OK for Emacs 29?

bug#64923: 29.1; white background glitch with new graphical frames

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Martin Rudalics <rudalics@gmx.at>,
>   64923@debbugs.gnu.org
> Date: Sun, 30 Jul 2023 10:08:32 +0800
> 
> Eli, is this OK for Emacs 29?

Not before Emacs 29.1 is released, no.

bug#64923: 29.1; white background glitch with new graphical frames

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Martin Rudalics <rudalics@gmx.at>,
>>   64923@debbugs.gnu.org
>> Date: Sun, 30 Jul 2023 10:08:32 +0800
>> 
>> Eli, is this OK for Emacs 29?
>
> Not before Emacs 29.1 is released, no.

But because of this bug, frame contents will not be displayed for some
users, unless they configure --without-cairo.

bug#64923: 29.1; white background glitch with new graphical frames

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tmdmelo@gmail.com,  rudalics@gmx.at,  64923@debbugs.gnu.org
> Date: Sun, 30 Jul 2023 13:59:48 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Martin Rudalics <rudalics@gmx.at>,
> >>   64923@debbugs.gnu.org
> >> Date: Sun, 30 Jul 2023 10:08:32 +0800
> >> 
> >> Eli, is this OK for Emacs 29?
> >
> > Not before Emacs 29.1 is released, no.
> 
> But because of this bug, frame contents will not be displayed for some
> users, unless they configure --without-cairo.

"There's always one more bug."  If we chase every minor issue, we will
never release Emacs 29.1.  Sorry.

bug#64923: 29.1; white background glitch with new graphical frames

[Eli Zaretskii]

> Cc: rudalics@gmx.at, tmdmelo@gmail.com, 64923@debbugs.gnu.org
> Date: Sun, 30 Jul 2023 08:21:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Martin Rudalics <rudalics@gmx.at>,
> >   64923@debbugs.gnu.org
> > Date: Sun, 30 Jul 2023 10:08:32 +0800
> > 
> > Eli, is this OK for Emacs 29?
> 
> Not before Emacs 29.1 is released, no.

You can install now, since Emacs 29.1 was released.

bug#64923: 29.1; white background glitch with new graphical frames

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: rudalics@gmx.at, tmdmelo@gmail.com, 64923@debbugs.gnu.org
>> Date: Sun, 30 Jul 2023 08:21:05 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > From: Po Lu <luangruo@yahoo.com>
>> > Cc: Eli Zaretskii <eliz@gnu.org>, Martin Rudalics <rudalics@gmx.at>,
>> >   64923@debbugs.gnu.org
>> > Date: Sun, 30 Jul 2023 10:08:32 +0800
>> > 
>> > Eli, is this OK for Emacs 29?
>> 
>> Not before Emacs 29.1 is released, no.
>
> You can install now, since Emacs 29.1 was released.

Thanks, but I'm still waiting for Thiago to ack.
I didn't realize the release of Emacs 29.1 was so imminent.

bug#64923: 29.1; white background glitch with new graphical frames

[Thiago Melo]

On Sun, Jul 30, 2023 at 2:08 AM Po Lu <luangruo@yahoo.com> wrote:
> Does this fix both your problems?
>
> diff --git a/src/xfns.c b/src/xfns.c
> index 55bcfb8e20e..222e24f1326 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -5393,6 +5393,17 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
>    gui_default_parameter (f, parms, Qfullscreen, Qnil,
>                           "fullscreen", "Fullscreen", RES_TYPE_SYMBOL);
>
> +#ifdef USE_CAIRO
> +  /* Set the initial size of the Cairo surface to the frame's current
> +     width and height.  If the window manager doesn't resize the new
> +     frame after it's first mapped, Emacs will create a surface with
> +     empty dimensions in response to to the initial exposure event,
> +     which will persist until the next time it's resized.
> +     (bug#64923) */
> +  x_cr_update_surface_desired_size (f, FRAME_PIXEL_WIDTH (f),
> +                                   FRAME_PIXEL_HEIGHT (f));
> +#endif /* USE_CAIRO */
> +
>    /* Make the window appear on the frame and enable display, unless
>       the caller says not to.  However, with explicit parent, Emacs
>       cannot control visibility, so don't try.  */

Yes, this patch fixes both issues.  Very insightful, Po Lu, thanks.

bug#64923: 29.1; white background glitch with new graphical frames

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

Thiago Melo <tmdmelo@gmail.com> writes:

> Yes, this patch fixes both issues.  Very insightful, Po Lu, thanks.

It's been installed, so I'm closing this bug now.  Thanks.