Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Weird double shadow on some GTK3 apps #189

Open
hexchain opened this Issue · 50 comments
@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
Collaborator

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.

Under xcompmgr

@richardgv
Collaborator

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
Collaborator

@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.

@echoid

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.

@memeplex memeplex referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@memeplex memeplex referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@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" ]

@memeplex memeplex referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@richardgv richardgv referenced this issue from a commit
@richardgv richardgv 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.
9a99e7a
@richardgv
Collaborator

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 #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

@richardgv
Collaborator

@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
Collaborator

@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: baskerville/bspwm#133 and it works.

@richardgv
Collaborator

@mar04:

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

@richardgv richardgv added the bad-app? label
@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

screenshot from 2015-04-10 16-50-08
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
@Frodox

@tigamai thank you very much, works fine :)

@onodera-punpun

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
Something went wrong with that request. Please try again.