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.