bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov]

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.