Chromium gets opacity even tho my conf says 1.0 on everything.

[Torxed]

Hi.

Running compton with all opacity settings to 1.0 just to get nothing transparent gives me a Chromium window that's still semi-transparent.

Don't know where to begin on this issue so any questions regarding settings and what not would be appreciated.

Here the startup: compton --config .compton.conf -b
And here's the config:

# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "name = 'Notification'", "class_g = 'Conky'", "class_g ?= 'Notify-osd'" ];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = false;

# Opacity
menu-opacity = 1;
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = true;
alpha-step = 0.06;
# inactive-dim = 0.2;
# inactive-dim-fixed = true;
# blur-background = true;
# blur-background-frame = true;
blur-background-fixed = false;
blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'" ];

# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.05;
fade-out-step = 0.05;
# no-fading-openclose = true;
fade-exclude = [ ];

# Other
backend = "xrender"
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "none";
dbe = false;
paint-on-overlay = false;
sw-opti = false;
unredir-if-possible = false;
focus-exclude = [ ];
detect-transient = true;
detect-client-leader = true;
invert-color-include = [ ];

# GLX backend
# glx-no-stencil = true;
glx-copy-from-front = false;
# glx-use-copysubbuffermesa = true;
# glx-no-rebind-pixmap = true;
glx-swap-method = "undefined";

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; opacity = 1; focus = true; };
};

[richardgv]

Huh, you provided a lot of information, Torxed, but which Chromium window is transparent in what situation? Is it the main window, or the dialog windows, or something else? Mind posting a screenshot?

Typically, compton honors _NET_WM_WINDOW_OPACITY property from the frame window the most, then _NET_WM_WINDOW_OPACITY from client window (if --detect-client-opacity is enabled), then default opacity of window type, then inactive_opacity (unless --inactive-opacity-override is used). So you may wish to check if your windows have _NET_WM_WINDOW_OPACITY property set somehow.

And some ARGB windows may resemble a transparent window in some cases. But usually, ARGB windows have opaque WM frames while the real transparent windows have semi-transparent ones. Depth: 32 in xwininfo output is an indication of such a window. I'm not aware of Chromium using ARGB windows except the drag-and-drop windows, though.

By the way, for compton, 100% opacity means use the default opacity. A window with _NET_WM_WINDOW_OPACITY of 0xFFFFFFFF (100%) behaves like it doesn't have the property. --inactive-opacity 1.0 is fully equivalent to --inactive-opacity 0.0 (aka disabling the feature). menu-opacity = 1.0 means the default, as well.

By the way 2, you could come to our IRC channel (#compton @ FreeNode) for support as well.

[Torxed]

Sure thing, as you can see from the image below.. the active window (chromium) has opacity but the inactive window behind does not. And if i activate the "backgrounded" window it keeps 0% transparency (100% opacity) and switching back does nothing.

How do i check my _NET_WM_WINDOW_OPACITY to be specific?
I'm diverse in terms of programming and what not but lack specifics in Linux, this being one of those specifics.

Oddly enough opening a new xterm window appears to do the trick..
Check this video for issue and temporary "solution"(?): http://youtu.be/otcrRkJqkMM

[richardgv]

It feels like a compton bug if opening a xterm window appears a cure... But weird, nobody ever reported anything like this!

Several things you can try:

1. Minimize Chromium window and restore;

2. Enable WM frame on Chromium window;

3. Try loading no compton configuration (compton --config /dev/null).

4. Look for _NET_WM_WINDOW_OPACITY on your Chromium window:

   $ xprop _NET_WM_WINDOW_OPACITY
   # Then click on the window with problem
   $ xprop -frame _NET_WM_WINDOW_OPACITY
   # Then click on the window with problem

5. Use GLX backend, to check if it's a bug in our XRender code: compton --backend glx.

6. Turn off your inactive-opacity-override. I guess it couldn't really cause the issue, but it's a bad thing to leave it on.

[Torxed]

1: Ok so minimizing Chromium doesn't help.
2: Not sure how to get a WM frame on Chromium but i'll google it and get back on that part.
3: loading with /dev/null didn't help, in fact basically the same thing happens.
4: here's what that gave me:

[doxid@faparch ~]$ xprop _NET_WM_WINDOW_OPACITY
_NET_WM_WINDOW_OPACITY:  not found.
[doxid@faparch ~]$ xprop -frame _NET_WM_WINDOW_OPACITY
_NET_WM_WINDOW_OPACITY(CARDINAL) = 3221225471

5: Using GLX backend did not help, but it did make things smoother for some reason (transitions and what not.. or i'm just imagining things)

6: Didn't help, but didn't hurt so i'll leave that off for now.

[richardgv]

_NET_WM_WINDOW_OPACITY(CARDINAL) = 3221225471

That's it. _NET_WM_WINDOW_OPACITY told compton to paint Chromium window with 75% opacity... So compton did it. compton only modifies this property if you use --opacity-rule -- and apparently this is not the case. Now I guess you need to investigate which program is actually modifying this property. Huh, certain WM (awesome) could do this. You may also look into your Chromium configuration (like, try to create a new profile), but a property set on frame window is less likely to be created by the application itself. And things like devilspie, if you are using any...

[Torxed]

I hate to be the noob in a conversation (not saying i was hoping you were, just didn't think i was this far off the bat on this issue)..
But i think it was another composit manager doing the work some how.

I had Xcompmgr installed (not active), and i wasn't pleased with it's performance so i've had it deactivated for a few weeks. But for some reason it interfered with compton..

Again, don't know how the hell this is possible considering it was inactive but i'm sorry for wasting your time in this manner, i'm glad that you give this fast and swift support tho! Keep it up!

[richardgv]

But i think it was another composit manager doing the work some how.

I had Xcompmgr installed (not active), and i wasn't pleased with it's performance so i've had it deactivated for a few weeks. But for some reason it interfered with compton..

As far as I know, two compositors can't run together (because they both try to XCompositeRedirectSubwindows(ROOT_WINDOW)). compton will quit immediately if xcompmgr is running, and vice versa. So "xcompmgr is interfering with compton" doesn't sound particularly right for me.

On many distros, xcompmgr is bundled with or depends on transset, a small utility that could set _NET_WM_WINDOW_OPACITY. I would suspect if you have something on your system that tries to call it.

By the way, as you may already know, compton is a fork of xcompmgr and the performance of our X Render backend is, typically, slightly worse than xcompmgr (because a lot of added features and logic). GLX backend is another thing, and compton indeed doesn't have as many bugs as xcompmgr does, as far as I could see, though.

i'm glad that you give this fast and swift support tho! Keep it up!

Thanks! :-)

[actionless]

mb it's related to new chrome's aura thing?
because after update to it (they're saying what it uses it's own compositor) i noticed some messages in compton's log when i'm switching to chromium:

[    13.85 ] error    9 BadDrawable  request  134 minor   14 serial   9177: "BadDrawable (invalid Pixmap or Window parameter)"
[    13.85 ] error  136 XSyncBadFence request  134 minor   18 serial   9178: "BadFence"
[    13.85 ] error  136 XSyncBadFence request  134 minor   15 serial   9179: "BadFence"
[    13.85 ] error  136 XSyncBadFence request  134 minor   19 serial   9180: "BadFence"
[    13.85 ] error  136 XSyncBadFence request  134 minor   18 serial   9181: "BadFence"
[    13.85 ] error  136 XSyncBadFence request  134 minor   16 serial   9182: "BadFence"
[    13.85 ] error    9 BadDrawable  request   14 minor    0 serial   9183: "BadDrawable (invalid Pixmap or Window parameter)"
glx_bind_pixmap(0x01e00514): Failed to query Pixmap info.
win_paint_win(0x01000038): Failed to bind texture. Expect troubles.
win_paint_win(0x01000038): Missing painting data. This is a bad sign.
[    13.86 ] error  136 XSyncBadFence request  134 minor   18 serial   9214: "BadFence"
[    13.86 ] error  136 XSyncBadFence request  134 minor   15 serial   9215: "BadFence"
[    13.86 ] error  136 XSyncBadFence request  134 minor   19 serial   9216: "BadFence"
[    13.86 ] error  136 XSyncBadFence request  134 minor   18 serial   9217: "BadFence"
[    13.86 ] error  136 XSyncBadFence request  134 minor   16 serial   9218: "BadFence"
[    13.86 ] error  136 XSyncBadFence request  134 minor   17 serial   9219: "BadFence"
[    13.86 ] error    4 BadPixmap    request   54 minor    0 serial   9229: "BadPixmap (invalid Pixmap parameter)"

but i have "xrender-sync-fence = true;" turned on, and it looks like it's generating that exception.

so after disabling that option i can't reproduce that no more

[richardgv]

@actionless:

These message are (usually) harmless. See #52 for an explanation. (Seemingly it's the issue that I reference most frequently. :-D) They are there simply because I didn't silence them.

Are you having the same weird transparency issue, or just saw too many error messages?

I'm not really sure about what Aura is doing, but I doubt if it's affecting compton. chromium-36.0.1985.18 is only compositing some of its own sub windows into its main window, as far as I could see. Some Chromium now stop getting shadow from compton, but I don't see anything more serious.

[actionless]

@richardgv,
no, i don't hv any serious problems because of chromium

only have some issues with compton and awesome when it's working too long -- it starts to react very slowly, it fixes after compton restart.
but i don't have any useful logs to show (ie no any strange error messages in that time), so i don't hv enought info to create an issue regarding that

[richardgv]

@actionless:

only have some issues with compton and awesome when it's working too long -- it starts to react very slowly, it fixes after compton restart.

Which is very hard to tell...

1. Two simple things to check are the memory usage and X resource usage (reported by xrestop). If they are unusually high after it's working too long, it could be some sort of resource leakage. I'm not aware of a way to check for GL resource leaks on Unix, unfortunately (but probably one could be written by parsing apitrace's output).
2. Do you see high CPU usage when the issue occurs? If you do, profiling results may bring us some hints.
3. Does it happen if you use an empty configuration (compton --config /dev/null)?
4. It may also be related to the driver.
5. You may wish to test with the latest version from git repo.

[actionless]

@richardgv
thanks, if i will find some useful info using the ways provided above, i will create a ticket