GNU bug report logs - #64923
29.1; white background glitch with new graphical frames

Previous Next

Full log

View this message in rfc822 format

From: Thiago Melo <tmdmelo <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Martin Rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 64923 <at> debbugs.gnu.org
Subject: bug#64923: 29.1; white background glitch with new graphical frames
Date: Sun, 30 Jul 2023 13:07:42 +0000

On Sun, Jul 30, 2023 at 2:08 AM Po Lu <luangruo <at> 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.

Previous Next

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