Visual artifacts in TerminalScreen widget when running under Mutter/GNOME Shell with transparent background

[marcxjo]

A few prefaces:

1. Big fan of MATE and the MATE devs' excellent work. No criticism intended, only constructive observation.
2. This report encompasses multiple atomic issues; based on the common triggering setting, I believe they are all tightly related.
3. I realize MATE Terminal in GNOME Shell/Mutter is probably not a high-priority use case; feel free to bin this report if appropriate. I call out the observed behavior chiefly because my concern is that it implies that the current solution for transparency doesn't appear to solve its purported problem for all plausible use cases.
4. I am absolutely willing and happy to put my money where my mouth is and submit a PR to resolve this issue. I'm mainly soliciting feedback on whether such a fix is desired and attempting to provide evidence for why I believe it would be a reasonable contribution.

Expected behaviour

When running MATE Terminal in GNOME Shell/Mutter with a transparent profile enabled, the terminal window should behave as normal with the exception that widgets/wallpaper behind the screen widget are partially visible (proportionately to transparency percentage).

Actual behaviour

The terminal screen widget produces strange artifacting behavior, such as "traces" of menubar menus left visible after clicking away.

Transparency is inconsistent and can be inadvertently toggled off for the remainder of the terminal session.

Dragging the window produces artifacts of the terminal window within the screen widget.

Steps to reproduce the behaviour

Environment:

• Run MATE Terminal in GNOME Shell 44
• In the current profile, set the background type to transparent (if not already transparent)
• Set transparency to 10-20% (in order to make the behavior obvious)

Menubar artifacts:

• In the main app window's menubar:
  • Open a menu
  • Drag the cursor across the menubar, opening additional menus
  • Observe that visible artifacts of each opened menu will persist in the screen widget (i.e., a "copy" or visual "imprint" of the menu will remain even after clicking and/or dragging away from the menu)

Transparency loss:

• In a terminal profile with transparency enabled, toggle the background type to "Solid color"
• Toggle the background type back to "Transparent background"
  • Observe that transparency is not restored to the screen widget

Inconsistent transparency:

• While running a terminal profile with transparent background, press the Super/"Windows" key to activate the GNOME Shell Overview
  • Note that the terminal window appears to display transparency with the correct color/percentage in this view
  • Press the Esc key
  • Observe "jittering" behavior in the terminal screen widget (in my case, vertical lines which will rapidly and inconsistently appear and disappear)

Dragging behavior:

• While running a terminal profile with transparent background near the southeast corner of your monitor, drag the window northwest
• Observe that the window's menubar and frame are rendered inside of the terminal screen widget while dragging

MATE general version

1.26

Package version

$ pacman -Q mate-terminal
mate-terminal 1.26.1-1

Linux Distribution

Arch Linux, packages up-to-date as of the hour prior to this report Relevant package versions:

$ pacman -Q mutter gnome-shell
mutter 44.1+r2+g82bd40dcbc-1
gnome-shell 1:44.1-3

Link to bugreport of your Distribution (requirement)

Not filed at this time - can file if necessary, but I strongly believe this is an upstream issue

[marcxjo]

One observation that I want to call out: the code currently does not make use of gtk_widget_app_set_paintable to effect background transparency for the screen widget. Based on discussion in #240, the upshot of the discussion seems to have been that

• solving this issue while preserving the current approach to transparency would require loading-in a CSS fix on startup for the menubar (using either a flat CSS file or gresource)
• using CSS to solve this specific issue would be a hack

I understand the reasoning and agree, but I want to note that gtk_widget_set_app_paintable is the common solution employed by a few of the major GTK3/VTE apps, including tilix, xfce4-terminal, and previously gnome-terminal*, and at least based on my own repeated testing over the past few days, transparency appears to behave as expected for all such applications under GNOME Shell. xfce4-terminal makes use of this approach without needing to load in any resources to ensure menubar opacity.

I suspect it would not be terribly difficult to re-implement this approach without needing a CSS fix for the menubar, but as an interim fix and to ensure consistent behavior, I'm not sure it's the worst possible solution.

* I use a patched gnome-terminal which restores this specific implementation to enable transparency, and I can confirm that it does not display any unusual behavior when running with transparency enabled under GNOME Shell.

[lukefromdc]

MATE supports running under multiple window managers. We ship Marco, and Compiz is a widely used replacement as it was in the GNOME 2 days. Gnome-shell is simply a combined window manager and panel replacement. A rendering artifact in gnome-shell implies a similar problem may be possible under other window managers too, I suspect Mutter would be affected if nothing else. Since Cinnamon is a gnome-shell fork, it too could be affected though since that fork was long ago there could be different behavior.

I just tested this, and found that on my setup (Debian Unstable) transparency did not work at all in gnome-shell, and in Cinnamon was composited to the desktop background, ignoring all windows between. Both tests were with gnome-shell --replace and cinnamon --replace respectively, leaving caja managing the desktop

[marcxjo]

@lukefromdc Thanks very much for testing on your setup, especially confirming Cinnamon behavior.

I've pushed up #434 and am seeing desired behavior when applied to latest master. Not much to it, but any feedback regarding style, implementation, etc. is highly appreciated.

[marcxjo]

Closing as apparently fixed by #434.

Happy to contribute further if additional/related transparency issues are surfaced.