Open akemrir opened 4 years ago
what are you trying to achieve? there is a lot of things in your configuration file so it will be better if you describe what behavior you expect and what behavior you get. and correct the issue title, please. it should briefly describe the issue.
I want to make terminal windows 5% transparent and borders 25% transparent. That's why I've set:
"95:class_g *?= 'xfce4-terminal'",
....
frame-opacity = 0.75;
But borders on some applications are not properly coloured.
i assume that on your screenshot two windows on the right are inactive and have properly colored borders, the top left window is inactive too, but has not properly colored borders and the bottom left window is active and has properly colored borders? am i right?
top right - proper bottom right - proper top left - invalid completely bottom left - invalid - hue is right, but is too bright
@mighty9245 https://github.com/chjj/compton/issues/240 maybe this one is related?
and this one https://github.com/xmonad/xmonad/pull/9
are you using experimental backends?
I`ve tested this on xrender and glx with same result
i mean, do you launch picom with --experimental-backends
? probably no tho
Nope. I don't use experimental backends option,
well, i can't reproduce this behavior running bspwm and kitty, so this is probably a qtile thing: either an upstream issue or a thing in qtile that picom handles incorrectly. wait for @yshui response.
Listen to fun part. I tried with kitty and it worked. But for xfce4-terminal not, check please this one exactly.
can't reproduce running xfce4-terminal too.
are you able to reproduce the issue with minimal configuration file? this behavior may be caused by other options.
frame-opacity = 0.75;
opacity-rule = [
"95:class_i = 'xfce4-terminal'"
];
So it looks like problem with qtile not compositor.
i would recommend to keep this issue open because this may be a bug with how picom handles some things as well and we could do something about this.
So let's do that way. After that check eventually I will ping qtile programmers.
Ok. I`ve done some investigation on this case and changed source code of qtile. I have forced chosen color of window border, but in function which is responsible on lowest level.
Problem with weird border color appears only when picom is running. I`ve experienced same problem with xcompmgr.
Without compositing manager borders looks fine and have same forced border color.
I`ve checked bspwm and dwm, there border colors are ok.
I observe the same behavior in my set up:
The firefox's border has bright translucent border while xterm and pcmanfm has correct border color. I have tried picom, compton, and xcompmgr; all with default configuration.
incorrect border color in firefox
correct border color in xterm and pcmanfm
@akemrir sorry, with the setup in your original post, what does it look like if you don't run picom?
@yshui borders have valid colors when picom is not running. When picom is running they look somewhat like they were rendered in addition mode in gimp.
hey, frame-opacity
is known to be broken on some setups, but i assume without it you can't achieve your idea?
@mighty9245 yes, exactly
@akemrir thanks. can i have a screenshot for reference?
I think the cause of my issue is probably a different one, but not sure if I should open a new ticket... I found that only when I enable webrender in firefox, the border has invalid color. I toggled gfx.webrender.all = true
and gfx.webrender.enabled = true
to enable webrender. Disabling webrender makes firefox border color normal again.
Just for fun, I installed alacritty and the invalid border color shows up for this one as well. Since both of these programs are written in Rust, I suspect my issue have something to do with how picom deal with Rust rendering.
xterm has some frame opacity with default config?
firefox has invalid border color with webrender enabled:
alacritty has the same issue
firefox has correct border color with webrender disabled and frame-opacity=1
without picom:
@yshui here it is https://imgur.com/a/6zdaThl
On this screenshot I am using gnome-terminal. But on alacritty and xfce-terminal result is same.
I think I might know what the problem is.
Looks like the RGB color is not properly pre-multiplied with the alpha value.
@akemrir BTW, does --experimental-backends
have the same problem?
@yshui same problem This could relate to this problem?
[ 13.03.2020 14:06:14.697 x_fence_sync ERROR ] Failed to trigger the fence.
[ 13.03.2020 14:06:14.697 paint_all_new ERROR ] x_fence_sync failed, xrender-sync-fence will be disabled from now on.
@akemrir I think I fixed this problem in --experimental-backends
, still investigating the old backends.
@linhvng Can you capture a trace of picom showing the invalid border color, with apitrace ?
I'm not sure if I have done the tracing correctly... the trace file was empty...
github does not allow me to upload .trace file so I just appended .zip to the end 24975.trace.zip
@linhvng ah, perhaps you are using the xrender backend? Does the glx backend work?
apitrace trace picom --backend glx
did the trick, here is the trace file :smile:
33430.trace.zip
here is the output of apitrace dump 33430.trace > 33430.trace.txt
33430.trace.txt
if it helps in looking at the log, I have a terminal open, run apitrace, then open alacritty and firefox, then switch back to the terminal and stop apitrace with Ctrl + C
.
here is the output of apitrace replay 33430.trace
error: drawable failed to resize: expected 1366x768, got 1302x736 156: message: shader compiler issue 1: FS SIMD8 shader: 5 inst, 0 loops, 24 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes. 156: message: shader compiler issue 2: FS SIMD16 shader: 5 inst, 0 loops, 34 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes. 156: message: shader compiler issue 3: VS SIMD8 shader: 28 inst, 0 loops, 116 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 448 to 336 bytes. 629: message: shader compiler issue 4: FS SIMD8 shader: 12 inst, 0 loops, 280 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 629: message: shader compiler issue 5: FS SIMD16 shader: 12 inst, 0 loops, 302 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 629: message: shader compiler issue 6: VS SIMD8 shader: 32 inst, 0 loops, 124 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 512 to 368 bytes. 639: message: shader compiler issue 7: FS SIMD8 shader: 12 inst, 0 loops, 282 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 639: message: shader compiler issue 8: FS SIMD16 shader: 12 inst, 0 loops, 302 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 639: message: shader compiler issue 9: VS SIMD8 shader: 22 inst, 0 loops, 90 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 352 to 288 bytes. 959: message: shader compiler issue 10: FS SIMD8 shader: 12 inst, 0 loops, 282 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 959: message: shader compiler issue 11: FS SIMD16 shader: 12 inst, 0 loops, 306 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 1219: message: shader compiler issue 12: FS SIMD8 shader: 12 inst, 0 loops, 282 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 1219: message: shader compiler issue 13: FS SIMD16 shader: 12 inst, 0 loops, 302 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 192 to 112 bytes. 43934: message: shader compiler issue 14: FS SIMD8 shader: 15 inst, 0 loops, 308 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 240 to 160 bytes. 43934: message: shader compiler issue 15: FS SIMD16 shader: 15 inst, 0 loops, 322 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 240 to 160 bytes. Rendered 449 frames in 1.04545 secs, average of 429.48 fps
@linhvng it appears your window manager is rendering the frame in a weird way...
The frame has an alpha value of 0 (completely transparent).
Can you also get a trace with frame-opacity set to 1?
output of apitrace trace picom --backend glx --frame-opacity=1
58224.trace.zip
output of apitrace dump 58224.trace > 58224.trace.txt
58224.trace.txt
@yshui if I have not mentioned yet, thank you for your quick response and for looking into this issue :pray:
@linhvng The border still looks transparent even when you set --frame-opacity=1
?
It is definitely weird how the border doesn't have the correct alpha value. I wonder if this is a bug in Xorg or the window manager.
@akemrir What window manager do you use? Can you also capture an apitrace so we could figure out if you have the same problem as @linhvng .
@linhvng The border still looks transparent even when you set
--frame-opacity=1
?
yessir
@yshui These problems are from qtile wm.
@akemrir @linhvng You should consider raising this issue to your respective window managers, I need their inputs to better understand this problem. You need to mention this in your report:
The window border have a color whose alpha value is 0, causing the border to be rendered improperly, because picom expects a premultiplied color
@yshui thanks for help, I am putting your conclusions here https://github.com/qtile/qtile/issues/692
I can reproduce with xfce4-terminal (and with Zoom) on dwm. This old patch for dwm doesn't work. I think I will try to contact the dwm maintainers.
I`ve tested awesomewm, and there this problem is not present. So this is related to WM directly.
Alright I found a solution for those of us on dwm. Get this patch for dwm which was modified from the alpha patch. Apply it and edit config.h to make everything opaque (look inside the patch to see how to do that). This fixes the border opacity/color problem for xfce4-terminal. I haven't tested it with other programs yet but it should work. This works no matter your picom opacity and dimming settings.
Just wanted to update that this doesn't work 100% of the time. I occasionally am still getting the bug.
Thanks!! I was having this problem for a long time already. Great patch! (well.. workaround)
There's actually an easier 1 line fix for this in dwm that I found here:
https://github.com/szatanjl/dwm/commit/1529909466206016f2101457bbf37c67195714c8
Hopefully helps some other people out.
There's actually an easier 1 line fix for this in dwm that I found here:
Hopefully helps some other people out.
That works way better. The alpha patch actually breaks a little when using the mouse to switch focus.
@yshui as far as I'm aware this is a wm problem so you can close the issue if you want.
Platform
Linux 5.4.1-arch1-1 #1 SMP PREEMPT Fri, 29 Nov 2019 13:37:24 +0000 Archlinux 64bit
GPU, drivers, and screen setup
NVidia GTX 1070, nvidia-drivers 440.36, one monitor
Environment
New installation of Qtile.
picom version
v7.5
Configuration:
Expected behavior
Correct border color, instead of transparent white.
Current behavior
Border color of inactive windows is transparent white, on active windows gets very bright color with transparency.
https://imgur.com/a/ciZMGy2
As you can see windows placed on top, both are inactive, but with different border color. When I turn off picom both have same color. I am not using rgba colours in qtile. I am leaving handling transparency to picom.
Terminal is xfce4-terminal. I have same problems on sakura