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.