Subject: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Fri, 24 Feb 2023 14:32:12 +0200

On 24/02/2023 02:59, Po Lu wrote:
> I suspect this may be a problem with damage tracking under GNOME's
> compositing manager.  Given that none of the output seems to be
> problematic.
> 
> The easy thing to do is to place a window containing changing content
> (such as an animation or image) behind Emacs, apply the following
> change:
> 
> diff --git a/src/xterm.c b/src/xterm.c
> index 5e6378db30d..8459dd33297 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -5222,37 +5222,37 @@ x_update_opaque_region (struct frame *f, XEvent *configure)
>     if (!FRAME_DISPLAY_INFO (f)->alpha_bits)
>       return;
>   
> -  if (f->alpha_background < 1.0)
> +  /* if (f->alpha_background < 1.0) */
>       XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
>   		     FRAME_DISPLAY_INFO (f)->Xatom_net_wm_opaque_region,
>   		     XA_CARDINAL, 32, PropModeReplace,
>   		     NULL, 0);
> -#ifndef HAVE_GTK3
> -  else
> -    XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> -		     FRAME_DISPLAY_INFO (f)->Xatom_net_wm_opaque_region,
> -		     XA_CARDINAL, 32, PropModeReplace,
> -		     (unsigned char *) &opaque_region, 4);
> -#else
> -  else if (FRAME_TOOLTIP_P (f))
> -    XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> -		     FRAME_DISPLAY_INFO (f)->Xatom_net_wm_opaque_region,
> -		     XA_CARDINAL, 32, PropModeReplace,
> -		     (unsigned char *) &opaque_region, 4);
> -  else
> -    {
> -      /* This causes child frames to not update correctly for an
> -	 unknown reason.  (bug#55779) */
> -      if (!FRAME_PARENT_FRAME (f))
> -	{
> -	  object_class = G_OBJECT_GET_CLASS (FRAME_GTK_OUTER_WIDGET (f));
> -	  class = GTK_WIDGET_CLASS (object_class);
> -
> -	  if (class->style_updated)
> -	    class->style_updated (FRAME_GTK_OUTER_WIDGET (f));
> -	}
> -    }
> -#endif
> +/* #ifndef HAVE_GTK3 */
> +/*   else */
> +/*     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), */
> +/* 		     FRAME_DISPLAY_INFO (f)->Xatom_net_wm_opaque_region, */
> +/* 		     XA_CARDINAL, 32, PropModeReplace, */
> +/* 		     (unsigned char *) &opaque_region, 4); */
> +/* #else */
> +/*   else if (FRAME_TOOLTIP_P (f)) */
> +/*     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), */
> +/* 		     FRAME_DISPLAY_INFO (f)->Xatom_net_wm_opaque_region, */
> +/* 		     XA_CARDINAL, 32, PropModeReplace, */
> +/* 		     (unsigned char *) &opaque_region, 4); */
> +/*   else */
> +/*     { */
> +/*       /\* This causes child frames to not update correctly for an */
> +/* 	 unknown reason.  (bug#55779) *\/ */
> +/*       if (!FRAME_PARENT_FRAME (f)) */
> +/* 	{ */
> +/* 	  object_class = G_OBJECT_GET_CLASS (FRAME_GTK_OUTER_WIDGET (f)); */
> +/* 	  class = GTK_WIDGET_CLASS (object_class); */
> +
> +/* 	  if (class->style_updated) */
> +/* 	    class->style_updated (FRAME_GTK_OUTER_WIDGET (f)); */
> +/* 	} */
> +/*     } */
> +/* #endif */
>   }
>   
> and see whether or not the problem can still be reproduced that way.

I haven't tried this one yet (busy bisecting), but I can report that a 
window behind Emacs, even when Emacs is not transparent, and when the 
window is not visible, can stop the problem from happening.

This bit me during bisecting: e.g. I can have a video in Firefox playing 
in the background (not visible), or the Telegram window open (not 
visible; no animations), and the problem goes away.

This probably contributed to not having this bug reported sooner as well.