Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird double shadow on some GTK3 apps #189

Open
hexchain opened this issue Apr 15, 2014 · 50 comments

Comments

Projects
None yet
@hexchain
Copy link

commented Apr 15, 2014

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

This comment has been minimized.

Copy link

commented Apr 15, 2014

same here (openbox + Archlinux)

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

@ledti

This comment has been minimized.

Copy link

commented Apr 15, 2014

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

This comment has been minimized.

Copy link

commented Apr 15, 2014

yes downgrading fixes the issue.

@richardgv

This comment has been minimized.

Copy link
Collaborator

commented Apr 15, 2014

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

This comment has been minimized.

Copy link
Author

commented Apr 16, 2014

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

This comment has been minimized.

Copy link

commented Apr 16, 2014

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.

Under xcompmgr

@richardgv

This comment has been minimized.

Copy link
Collaborator

commented Apr 16, 2014

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

This comment has been minimized.

Copy link
Author

commented Apr 17, 2014

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

@memeplex

This comment has been minimized.

Copy link

commented Apr 17, 2014

@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

This comment has been minimized.

Copy link
Collaborator

commented Apr 17, 2014

@memeplex:

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

@memeplex

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

@memeplex

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

This comment has been minimized.

Copy link

commented Apr 17, 2014

indeed, excluding _GTK_FRAME_EXTENTS@:c fixes the issue.

thanks!

@memeplex

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

Thanks all!

@memeplex

This comment has been minimized.

Copy link

commented Apr 17, 2014

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

@orschiro

This comment has been minimized.

Copy link

commented Apr 18, 2014

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

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

@ncmprhnsbl

This comment has been minimized.

Copy link

commented Apr 19, 2014

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

This comment has been minimized.

Copy link

commented Apr 19, 2014

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

@ncmprhnsbl

This comment has been minimized.

Copy link

commented Apr 19, 2014

yes, same for all suggested excludes.

@memeplex

This comment has been minimized.

Copy link

commented Apr 19, 2014

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

@ncmprhnsbl

This comment has been minimized.

Copy link

commented Apr 19, 2014

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

richardgv added a commit that referenced this issue Apr 19, 2014

Misc: Try to avoid evaluating conditions after window unmap & others
- Try to avoid evaluating conditions after window unmap/destruction.
  Unfortunately, frequently this doesn't work due to the asynchronous
  nature of X.

- Add _GTK_FRAME_EXTENTS exclusion rules to compton.sample.conf. Thanks
  to memeplex, hexchain, and others for info. (#189)

- Add debugging option --show-all-xerrors, and other debugging changes.
  Doc update.
@richardgv

This comment has been minimized.

Copy link
Collaborator

commented Apr 19, 2014

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

This comment has been minimized.

Copy link

commented Apr 19, 2014

@richardgv regarding the black rectangle, have you read my last comment in #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

This comment has been minimized.

Copy link

commented Apr 25, 2014

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

@mar04

This comment has been minimized.

Copy link

commented May 1, 2014

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

@richardgv

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2014

@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

This comment has been minimized.

Copy link

commented May 1, 2014

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

This comment has been minimized.

Copy link

commented May 1, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented May 2, 2014

@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

This comment has been minimized.

Copy link

commented May 2, 2014

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

@richardgv

This comment has been minimized.

Copy link
Collaborator

commented May 2, 2014

@mar04:

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

@richardgv richardgv added the bad-app? label May 17, 2014

@gianlucapettinello

This comment has been minimized.

Copy link

commented Jun 22, 2014

@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

This comment has been minimized.

Copy link

commented Aug 23, 2014

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

This comment has been minimized.

Copy link

commented Aug 23, 2014

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

This comment has been minimized.

Copy link

commented Dec 12, 2014

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

@actionless

This comment has been minimized.

Copy link

commented Dec 12, 2014

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

This comment has been minimized.

Copy link

commented Dec 12, 2014

Works, but ugly shadow is back.

@actionless

This comment has been minimized.

Copy link

commented Dec 12, 2014

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

This comment has been minimized.

Copy link

commented Dec 12, 2014

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

@actionless

This comment has been minimized.

Copy link

commented Dec 12, 2014

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

@tigamai

This comment has been minimized.

Copy link

commented Mar 1, 2015

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

This comment has been minimized.

Copy link

commented Apr 10, 2015

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

@rilian-la-te

This comment has been minimized.

Copy link

commented Apr 10, 2015

screenshot from 2015-04-10 16-50-08
Here is a screenshot of new GTK 3.16 behavior of GTK CSD Window

@ncmprhnsbl

This comment has been minimized.

Copy link

commented Apr 10, 2015

@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

This comment has been minimized.

Copy link

commented Apr 11, 2015

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
#189 (comment).

Schnouki added a commit to Schnouki/dotfiles that referenced this issue May 12, 2015

@Frodox

This comment has been minimized.

Copy link

commented May 24, 2015

@tigamai thank you very much, works fine :)

@snj33v

This comment has been minimized.

Copy link

commented Jun 16, 2015

@onodera-punpun

This comment has been minimized.

Copy link

commented Jun 18, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.