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.