Every So Slighty Transparent when set at 99

[anomiet]

Hello,

So far, compton is the closest match to what I'm looking for in a compositor, so thank you for all your hard work.

I have, however, one issue that is rather bothersome. When I set an opacity rule to 99, that window is still ever so slightly transparent. This becomes very apparent whenever the window is using dark colors (particularly grays).

I run compton as follows:

compton -bG --config /home/anomie/.compton.conf --opacity-rule "99:class_g != 'Terminator'" &

And the config:

backend = "glx";
paint-on-overlay = true;
glx-no-stencil = true;
glx-no-rebind-pixmap = true;
vsync = "opengl-swc";

fading = true; # Fade windows during opacity changes.
fade-delta = 4; # The time between steps in a fade in milliseconds. (default 10).
fade-in-step = 0.03; # Opacity change between steps while fading in. (default 0.028).
fade-out-step = 0.03; # Opacity change between steps while fading out. (default 0.03).
#no-fading-openclose = true; # Fade windows in/out when opening/closing

detect-client-opacity = true;

inactive-opacity = 0.7;         # Default opacity of inactive windows. (0.0 - 1.0)
active-opacity = 0.9;           # Default opacity for active windows. (0.0 - 1.0)
frame-opacity = 1.0;

I'm basically trying to have transparency only on Terminator terminals and nothing else. I know I can set everything to 1.0 in my config and then just make a rule for terminator, but I want inactive-opacity and active-opacity to apply to all terminator windows which seems to not work with --opacity-rule.

Thank you, -anomie

Edit: Forgot to mention. I'm on ubuntu 12.04 running awesome 3.4.11

[richardgv]

1. I'm not able to reproduce the issue you reported with compton-git-v0.1_beta2-2013-10-21 and awesome-3.5.2.
2. Older versions of compton (<0.1_beta2) have a bug on x86 systems that all matched windows are given <=50% opacity, and the opacity-rule configuration file option is broken on those versions as well.
3. Awesome has built-in transparency setter, and it's recommended to use it over compton's --opacity-rule. It could interfere with --opacity-rule if you used it in your awesome configuration.
4. Does all other windows exhibit the issue? Could you please run xprop -frame _NET_WM_WINDOW_OPACITY, select a buggy window, and tell me the result? The normal output is _NET_WM_WINDOW_OPACITY(CARDINAL) = 4252017622. Do these windows respect your active-opacity/inactive-opacity or has an opacity that never changes? Could you please provide a screenshot?
5. By the way, compton reads ~/.compton.conf by default (though ~/.config/compton.conf has higher priority), so there's no need to specify the configuration file path with --config.

[anomiet]

Sorry for the long delay (and thanks for being so prompt). Been at work all day and then I decided to remove the version I got from ppa:richardgv/compton (which was significantly older) and compile it from git to get the latest updates. Anyway, I got the same results initially. I did the same thing I first described above and then simply running

compton -bG

along with opacity set to 0.9 in awesome's rc.lua. (setting it to 1.0 is like setting it to 100 with the --opacity-rule flag). Each gave me the same results I had on the older build. Here is a screenshot of Firefox with a gray image. I also uploaded my wallpaper so you know what's peeking through since it's so close to being opaque.

Screenshot: http://i.imgur.com/Gsv73wS.jpg Wallpaper: http://i.imgur.com/TkuDOrU.jpg

But here's the weird thing, it isn't transparent when I set opacity in awesome to 0.9999999999999999 (I don't need so many 9s but I figured I might as well go to the max before it just turns into 1.0). :p It needs to be set to at least 0.9981 before I couldn't see through it any more.

At 0.9999999999999999, xprop returns:

_NET_WM_WINDOW_OPACITY(CARDINAL) = 4294967294

At 0.9981, xprop returns:

_NET_WM_WINDOW_OPACITY(CARDINAL) = 4286806857

At 0.99 (and with --opacity-flag at 99), xprop returns:

_NET_WM_WINDOW_OPACITY(CARDINAL) = 4252017622

The windows do not respect my active-opacity/inactive-opacity settings. However, with an opacity rule for Terminator in rc.lua set to 0.80, Terminator abides by them. This is actually what I want. I only want Terminator to be transparent and respect those rules and everything else be opaque at all times.

Thank you, -anomie

[richardgv]

1. Come to FreeNode/#compton if you are willing. We might be able to solve the issue quicker there.
2. It sounds like what would happen if you used X Render backend and a large --alpha-step, weird...
3. ppa:richardgv/compton provides a pretty outdated copy of compton since I haven't updated it after releasing 0.1_beta1, which is available in the Debian repo already.

Update:

1. I'm not able to see anything behind a window with opacity 4252017622 (99%) here.
2. Does using X Render backend help? In case your driver is doing something sickening.

3. You may start compton with --dbus, and query it about the opacity it used to draw a buggy window with:

   # Replace 0xc0010e with the ID of the frame of a buggy window (which you can get with `xwininfo -frame`)
   dbus-send --print-reply --dest=com.github.chjj.compton._0 / com.github.chjj.compton.win_get uint32:0xc0010e string:opacity

   And ensure it prints the same value xprop -frame _NET_WM_WINDOW_OPACITY shows.

[anomiet]

So using the same settings and method of running compton from my initial post except using backend=XRender; makes everything behave as expected. I'm using nvidia-319 driver if that reveals anything.

Running with dbus was consistent with xprop in every case.

Anyway, I'm just glad it's working exactly the way I want. Let me know if I can provide any information that my reveal what's going with glx backend.

Thank you, -anomie

[richardgv]

Anyway, I'm just glad it's working exactly the way I want. Let me know if I can provide any information that my reveal what's going with glx backend.

Good. :-) If you have the time, I would recommend you to acquire a GL trace with apitrace (use the latest version from git repo, not a stable release) and send it to us, with GLX backend. Such trace files are pretty large, so it might be a good idea to only let apitrace run for a few seconds.