The “black border” effects comes from the frame window resize.
The gdk_window_move_resize() in meta_ui_frame_move_resize() is what causes the border to become solid black, before it's repainted by the compositor.
With basic X11 clients, the delay between the gdk_window_move_resize() and the shadow being redrawn is so short that it cannot be seen, but when the X11 client is using a sync mechnaism, the update of the content is delayed until the client has finished updating its content, and in this case the black border is seen for a short time.
That explains why the black border shows most with clients with using NET_WM_SYNC protocol and server-side decorations.
As an experiment, commenting out the gdk_window_move_resize() in meta_ui_frame_move_resize() makes the problem disappear entirely:
The “black border” effects comes from the frame window resize.
The gdk_window_ move_resize( ) in meta_ui_ frame_move_ resize( ) is what causes the border to become solid black, before it's repainted by the compositor.
With basic X11 clients, the delay between the gdk_window_ move_resize( ) and the shadow being redrawn is so short that it cannot be seen, but when the X11 client is using a sync mechnaism, the update of the content is delayed until the client has finished updating its content, and in this case the black border is seen for a short time.
That explains why the black border shows most with clients with using NET_WM_SYNC protocol and server-side decorations.
As an experiment, commenting out the gdk_window_ move_resize( ) in meta_ui_ frame_move_ resize( ) makes the problem disappear entirely:
https:/ /gitlab. gnome.org/ GNOME/mutter/ blob/master/ src/ui/ frames. c#L656
whereas commenting out the call to build_and_ scan_frame_ mask() in meta_window_ actor_update_ shape_region( ) makes the black border visible continuously:
https:/ /gitlab. gnome.org/ GNOME/mutter/ blob/master/ src/compositor/ meta-window- actor.c# L1699