Weird double shadow on some GTK3 apps

[hexchain]

With those GTK3 applications that have their own shadow (and probably window border), if compton's shadow is turned on, those windows will have bigger square box with shadow surrounding them.

Screenshot with compton shadow on: http://i.imgur.com/AbWHh66.png compton shadow off: http://i.imgur.com/k0nFnT4.png

I'm using Openbox on Arch Linux.

[tritonas00]

same here (openbox + Archlinux)

http://postimg.org/image/4q9noai1b

[ledti]

Try downgrading to gtk3-3.12.0 (x86_64 or i686) and see if that fixes the problem. I noticed by chance that gtk3-3.12.1 is buggy with compton a few days ago.

[tritonas00]

yes downgrading fixes the issue.

[richardgv]

It probably is the expected behavior when GTK+ tries to draw the shadow itself, seemingly on an ARGB window, and you may simply need to --shadow-exclude those windows somehow. Could you please tell us in which application we could reproduce the issue?

[hexchain]

zenity --entry brings up a gtk3 inputbox on screen.

--shadow-exclude can be used, but it seems there's no way to exclude all GTK3 windows.

[memeplex]

I have the same problem but I would like to add that these client side decorated gtk3 dialogs work well under xcompmgr. Hopefully you will find a way to support the gtk3 csd madness.

[richardgv]

Thanks for all the info. Unfortunately it's no fun to test GTK+ 3.12 here. All my working systems are Gentoo, and looks like GTK+ 3.12.1 is not in Portage tree or gnome-next overlay. It would be easy to build GTK+ itself, but GNOME packages may need to be updated as I upgrade to GTK+ 3.12...

By the way, --shadow-exclude argb might be a working workaround. --shadow-exclude '_NET_WM_OPAQUE_REGION@:c' may also worth trying.

@memeplex:

As far as I know xcompmgr has bugs handling shadow on ARGB windows, that sometimes those shadows are not drawn, which probably is the reason you see it's working. --shadow-exclude argb has an equivalent effect.

[hexchain]

Thank you, --shadow-exclude '_NET_WM_OPAQUE_REGION@:c' works fine here.

[memeplex]

@richardgv argb and _NET_WM_OPAQUE_REGION are more or less fine but seem not to be selective enough. For example argb suppress shadows from xfce4-terminal while _NET_WM_OPAQUE_REGION does it for evince (and maybe any gtk3 app, I didn't test that). From trial and error I would suggest _GTK_FRAME_EXTENTS and, for openbox users, _OB_WM_ACTION_UNDECORATE. I haven't found any authoritative documentation about which atom csd windows are supposed to expose.

[richardgv]

@memeplex:

Combine them, like --shadow-exclude 'argb && _NET_WM_OPAQUE_REGION@:c', might work better. Not sure about _GTK_FRAME_EXTENTS.

[memeplex]

@richardgv take a look at this : GTK+ uses this property (_GTK_FRAME_EXTENTS) for CSD support. Looks like we have our guy.

[memeplex]

Knowing that csd will be part of our lives in the dark times coming, this could be done a default behavior or a specific cli option added to cope with this case.

[tritonas00]

indeed, excluding _GTK_FRAME_EXTENTS@:c fixes the issue.

thanks!

[memeplex]

There is one more quirk. If you have fading enabled for window opening/close these csd dialogs show a black area framed by the client rectangle upon close. This is very noticeable. fading=false fixes it but is overkilling. I'm not able to avoid the artifact with fade-exclude = [ "_GTK_FRAME_EXTENTS@:c" ];, not sure why (OTOH shadow-exclude = [ "_GTK_FRAME_EXTENTS@:c" ]; works well...).

[memeplex]

Related to this and this. Seemingly openbox specific. Also, what I stated before (that the exclusion wasn't avoiding the artifact) is not accurate: with the compositor running even fading=false shows the black rectangle, just that it's less noticeable.

[ghost]

I had the same shadow problem with Openbox on Arch. Excluding "_GTK_FRAME_EXTENTS@:c" fixed it for me.

Thanks all!

[memeplex]

Just in case you're interested I've reported the black rectangle issue in the openbox bugtracker.

[orschiro]

Thanks for the hints regarding shadow-exclude = [ "_GTK_FRAME_EXTENTS@:c" ]

This resolved the issue for me on Openbox with Gnome Screenshot.

[ncmprhnsbl]

using arch and openbox tried all the suggested shadow excludes, and while they fix gtk3 stuff, its a case of no shadows and no opacity effects for openbox managed stuff, including menus, window decoration, and unfocussed windows. and fading... fix one thing, breaking everything else..... compton-trans still works tho :)
example line from compton.conf:
shadow-exclude = [ "_NET_WM_OPAQUE_REGION" ]; [ "name = 'Notification'", "class_g = 'Conky'", "class_g ?= 'Notify-osd'", "class_g = 'Cairo-clock'" ]; is this syntax correct? not using glx backend, if thats relevent

[memeplex]

Did you tried shadow-exclude = [ "_GTK_FRAME_EXTENTS@:c" ]? This couldn't be matching anything but CSD crap.

[ncmprhnsbl]

yes, same for all suggested excludes.

[memeplex]

Syntax looks wrong anyway: ...];[.... Keep only the exclude I suggested, just to see.

[ncmprhnsbl]

Ah yes, thanks for clearing that up, didnt actually need those other excludes anyway. everything working correctly now using [ "_GTK_FRAME_EXTENTS@:c" ]

[richardgv]

Yes, _GTK_FRAME_EXTENTS@:c looks like the correct fix. (Not sure if the more conservative argb && _GTK_FRAME_EXTENTS@:c is better. At least it's better performance-wise.) Sorry for my previous misleading comments. The shadow and blur-background exclusion rules have been added to compton.sample.conf in 9a99e7a (richardgv-dev branch).

Both rules may fail to work on the moment the window gets destroyed, because of something hard to control for us. I will explain in #190 later.

I haven't looked into Openbox's code regarding the ARGB window fade out "black rectangle" issue, but what I could confirm is ARGB windows look correct when faded out on fvwm with compton, and xcompmgr fails in the same way with Openbox, so this probably is tied to some sort of behavior of Openbox.

[memeplex]

@richardgv regarding the black rectangle, have you read my last comment in https://github.com/chjj/compton/issues/131? Last night I debugged openbox thoroughly and the black rectangle appears way before the unmap event is handled by the wm, I'm 99% sure the client itself is clearing its contents. When I set a very noticeable fade step (so that the fade in/out take a number of seconds) I can clearly observe the same symptom in pekwm, fluxbox and awesome, but since these wms set a light background it's almost impossible to detect the (light) rectangle if the fading out is quick or excluded. Besides that, if you put a breakpoint at the beginning of client_unmanage in openbox you will discover that:

1. The CSD dialogs are already black at that point (as I already mentioned).
2. (1) happens with and without compton being present.
3. (1) doesn't happen for regular windows (for example, for the equivalent gtk2 stock dialog).

[amatriain]

I was having the same problem with Arch, Xfce + Compton. Adding "_GTK_FRAME_EXTENTS@:c" to my shadow-exclude array fixed it. Thanks!

[mar04]

That fix doesn't work for me. Here is my config:

shadow-exclude = [ "_GTK_FRAME_EXTENTS@:c" ];
backend = "glx";
vsync = "opengl";
glx-no-stencil = true;
inactive-dim = 0.4;
use-ewmh-active-win = true;
mark-wmwin-focused = true;
mark-ovredir-focused = true;

I'm using Arch with gtk 3.12.1-2, compton from git and i3-wm. Here are two screenshots of file-roller

• with compton: http://postimg.org/image/c204cuhn1/
• without compton: http://postimg.org/image/vgrk8nsf3/

[richardgv]

@mar04:

I can't see an issue from your screenshots. Mind telling me the exact problem you found?

1. file-roller (and some other GTK+ 3) uses rounded corners + shadow when it detects a compositor running and a plain decoration otherwise. The shadow is not drawn by compton. And both look good.
2. compton will --inactive-dim the whole ARGB file-roller window, might look somewhat ugly for floating WMs but it doesn't look too bad in your screenshot -- if it becomes a problem, use --focus-exclude to remove the dim on those windows.
3. I remember i3 isn't playing too well with ARGB windows, though, but the problem is not visible in your screenshots.

[mar04]

I probably misunderstood what this issue is about. I just want to get rid of that extra space around windows of gnome 3 apps. Can I achieve that through some compton setting?

[ncmprhnsbl]

re:mar04. this issue also arises in openbox when using 'GrowToEdge' and 'MoveToEdge' keybinds. as richardgv points out its a gtk3 app ARGB window issue(providing phanton edge) although, the gtk3 guys will probly tell you its an i3 ,openbox, [insert favourite wm] issue. only compton based 'solution' at the moment would be turn off shadows completely, i guess.

[richardgv]

@mar04:

I probably misunderstood what this issue is about. I just want to get rid of that extra space around windows of gnome 3 apps. Can I achieve that through some compton setting?

I see.

1. Unfortunately, it's GTK+ 3 and the application which controls whether a window uses CSD, not compton.
2. As far as I could see, GTK+ 3.12.1 provides a switch to turn on CSD on windows that doesn't have it by default (the environment variable GTK_CSD=1) but you can't turn CSD off with this switch (stupid!).

3. I briefly looked into its source code and only found one "legal" way to disable CSD completely: Make GTK+ 3 believe you don't have a compositor. To make GTK+ 3 and other apps believe there's no compositor running, comment out the block of XSetSelectionOwner() in register_cm() of src/compton.c in compton:

    {
      unsigned len = strlen(REGISTER_PROP) + 2;
      int s = ps->scr;
   
      while (s >= 10) {
        ++len;
        s /= 10;
      }
   
      char *buf = malloc(len);
      snprintf(buf, len, REGISTER_PROP "%d", ps->scr);
      buf[len - 1] = '\0';
      XSetSelectionOwner(ps->dpy, get_atom(ps, buf), ps->reg_win, 0);
      free(buf);
    }

   But, as you may have realized, it doesn't only make GTK+ believe there's no compositor. It could break cairo-dock, cairo-clock, and various other apps that check for the presence of a compositor, and some apps fallback to uglier modes when they find no compositor running.

4. The illegal (but presumably, better) way is to hack GTK+ 3's source code so that it believes CSD is not supported. I found the relevent code in gtk+-3.12.1/gtk/gtk-window.c, line 3603:

   static gboolean
   gdk_window_supports_csd (GtkWindow *window)
   {
    GtkWidget *widget = GTK_WIDGET (window);
   
   #ifdef GDK_WINDOWING_X11
    if (GDK_IS_X11_DISPLAY (gtk_widget_get_display (widget)))
      {
        GdkScreen *screen;
        GdkVisual *visual;
   
        screen = gtk_widget_get_screen (widget);
   
        if (!gdk_screen_is_composited (screen))
          return FALSE;
   
        /* We need a visual with alpha */
        visual = gdk_screen_get_rgba_visual (screen);
        if (!visual)
          return FALSE;
      }
   #endif
   
   // Blah blah blah...
   
    return TRUE;
   }

   I believe making the function return FALSE will prevent GTK+ 3 from using CSD. Hacking create_decoration(), etc. might work as well.

5. Since I only briefly looked at the code, chances are there are cleaner ways to disable CSD on those GTK+ 3 apps that try to enable it. If you find a better way, I would be glad if you could share it to us. :-)

[mar04]

Thanks for explanation and all the tips. The least invasive way seems to be editing GTK theme. I found about it here: https://github.com/baskerville/bspwm/issues/133 and it works.

[richardgv]

@mar04:

Oh, yeah, that's a lot more cleaner. Thanks! :-)

[gianlucapettinello]

@mar04: I agree with you. Much much better. I discovered by myself googling and wanted to write here. But I realized that the trick was already found. Apologize for not reading

[PCMan]

Try this hack: https://github.com/PCMan/gtk3-nocsd I developed a fix to turn it off with LD_PRELOAD. This works with gtk+ 3.12 and is very selective.

[actionless]

i am using such workaround to remove additional shadow and borders from GTK3 apps:

$ cat ~/.config/gtk-3.0/gtk.css

.window-frame, .window-frame:backdrop {
  box-shadow: 0 0 0 black;
  border-style: none;
  margin: 0;
  border-radius: 0;
}

.titlebar {
  border-radius: 0;
}

[blasterbug]

@actionless good trick but since i'm using it, i can't resize GTK3 apps !

[actionless]

try to change to:

.window-frame:backdrop {
  box-shadow: 0 0 0 black;
  border-style: none;
  margin: 0;
  border-radius: 0;
}

.titlebar {
  border-radius: 0;
}

[blasterbug]

Works, but ugly shadow is back.

[actionless]

hm, mb smth like that?

.window-frame, .window-frame:backdrop {
  box-shadow: 0 0 0 black;
}
.window-frame:backdrop {
  border-style: none;
  margin: 0;
}

[blasterbug]

Haha, still not ! -.-" Should I'm looking for enabling forcing decoration on GTK3 apps?

[actionless]

yup, it's meant to be sorta of that.

[tigamai]

Had the same problem with gtk3/compton/i3. Using i3 4.8-3, gtk3 3.14.9-1, compton v0.1_beta2-5 on Arch. The other fixes suggested here didn't work for me.

The following fixed the problem for me:

You need to edit the file ~/.config/gtk-3.0/gtk.css

.window-frame, .window-frame:backdrop {
 box-shadow: 0 0 0 black;
 border-style: none;
 margin: 0;
 border-radius: 0;
}

.titlebar {
 border-radius: 0;
}

Source: https://www.reddit.com/r/i3wm/comments/2qk7c3/with_i3_compton_and_gtk3_make_rounded_corners_on/cn6zjme

[rilian-la-te]

On GTK 3.16 fix adding GTK_FRAME_EXTENTS to compton.conf not working anymore.

[rilian-la-te]

Here is a screenshot of new GTK 3.16 behavior of GTK CSD Window

[ncmprhnsbl]

@rilian-la-te , your screenshot looks like what i expect to see using the gtk-3.0/gtk.css theme edits in above posts, instead of the GTK_FRAME_EXTENTS exclude. ie compton is drawing shadows, the arb window decorations are turned off. maybe check your theme for those lines^ .. and because GTK_FRAME_EXTENTS don't make it past the theme theres nothing to exclude?

[theferrit32]

The issue you're seeing is unrelated to compton as far as I can tell.

The recent update gtk 3.16 seems to have broken pretty much every previous gtk3 that I've tried so far today. I'm unable to get gtk3 apps to reflect apps theme changes, and even the Gnome Adwaita theme is not working correctly even inside the Gnome 3 shell. Corners and window borders are extending out past the beveled edge and min/max/close buttons aren't working correctly.

On Fri, Apr 10, 2015 at 7:32 PM, ncmprhnsbl notifications@github.com wrote:

@rilian-la-te https://github.com/rilian-la-te , your screenshot looks like what i expect to see using the gtk-3.0/gtk.css theme edits in above posts, instead of the GTK_FRAME_EXTENTS exclude. ie compton is drawing shadows, the arb window decorations are turned off. maybe check your theme for those lines^ .. and because GTK_FRAME_EXTENTS don't make it past the theme theres nothing to exclude?

— Reply to this email directly or view it on GitHub https://github.com/chjj/compton/issues/189#issuecomment-91716043.

[Frodox]

@tigamai thank you very much, works fine :)

[snj33v]

@tigamai , https://github.com/shimmerproject/Numix/issues/206

[CamilleScholtz]

Very first link when googling "double shadow compton gtk3":

https://wiki.archlinux.org/index.php/Compton#Dual_shadow_on_some_GTK3_applications

it even has a fix.