bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Po Lu
Subject: bug#64923: 29.1; white background glitch with new graphical frames
Date: Sun, 30 Jul 2023 10:08:32 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]