Picom: Invalid border color on xfce4-terminal, sakura

Created on 17 Dec 2019 · 48Comments · Source: yshui/picom

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:

shadow = true;
detect-rounded-corners = true;
shadow-radius = 5;
shadow-offset-x = -6;
shadow-offset-y = 1;
shadow-opacity = 0.3;

shadow-ignore-shaped = false;
shadow-exclude = [
  # "override_redirect = 1 && !WM_CLASS@:s",
  # gromit-mpx
  # "class_g = 'root'" ,

  "class_g = 'Cairo-clock'" ,
  "class_g = 'Conky'",
  "class_g = 'CoverGloobus'",
  "class_g = 'St'",
  "class_g = 'Tilda'",
  "class_g = 'vokoscreen'",
  # "class_g ?= 'Dmenu'",
  # "class_g ?= 'Notify-osd'",
  "class_g ?= 'i3-frame'",
  "class_g ?= 'trayer'",
  "_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'",
  "_GTK_FRAME_EXTENTS@:c"
];

dropdown_menu = 1.0;
inactive-opacity = 1.0;
active-opacity = 1;
inactive-dim = 0.0;
blur-background = false;
blur-kern = "3x3box";
fading = false;
fade-delta = 1;
fade-in-step = 0.03;
fade-out-step = 0.03;
frame-opacity = 0.75;
fade-exclude = [ ];
backend = "glx";
mark-wmwin-focused = true;
mark-ovredir-focused = true;
detect-client-opacity = true;
unredir-if-possible = true;
refresh-rate = 0;
vsync = false;
dbe = false;
focus-exclude = [ "class_g = 'Cairo-clock'" ,
  "class_g = 'CoverGloobus'",
  "class_g = 'Tilda'",
  "class_g = 'Firefox'",
  "class_g = 'Firefox-esr'"
];
detect-transient = true;
detect-client-leader = true;
# invert-color-include = [ ];
glx-copy-from-front = false;
opacity-rule = [ "99:name *?= 'Call'",
  "95:name *?= 'Lynx'",
  "95:name *?= 'toot'",
  "95:name *?= 'nmon'",
  "95:name *?= 'httping'",
  "95:class_g *?= 'pavucontrol'",
  "95:class_g *?= 'xfce4-terminal'",
  "95:class_g *?= 'discord'",
  "95:class_g *?= 'surf' && name *?='suckless.org'",
  "95:class_g *?= 'tabbed'",
  "95:name *?= 'newsboat'",
  "100:class_g = 'XTerm' && !_NET_WM_STATE@:32a",
  "100:class_g = 'URxvt' && !_NET_WM_STATE@:32a",
  "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'",
  "96:_NET_WM_STATE@:32a *= '_NET_WM_STATE_STICKY'",
  "63:class_g = 'Bspwm' && class_i = 'presel_feedback'" ];

wintypes :
{
  tooltip :
  {
    fade = true;
    shadow = false;
    opacity = 0.85;
    focus = true;
  };
  fullscreen :
  {
    fade = true;
    shadow = true;
    opacity = 1;
    focus = true;
  };
};

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

upstream wde

Source

akemrir

Most helpful comment

There's actually an easier 1 line fix for this in dwm that I found here:

szatanjl/dwm@1529909

Hopefully helps some other people out.

That works way better. The alpha patch actually breaks a little when using the mouse to switch focus.

a-vrma on 7 May 2020

👍3

All 48 comments

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.

mighty9245 on 17 Dec 2019

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.

akemrir on 17 Dec 2019

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?

mighty9245 on 17 Dec 2019

top right - proper
bottom right - proper
top left - invalid completely
bottom left - invalid - hue is right, but is too bright

akemrir on 17 Dec 2019

@mighty9245
https://github.com/chjj/compton/issues/240
maybe this one is related?

and this one
https://github.com/xmonad/xmonad/pull/9

akemrir on 17 Dec 2019

are you using experimental backends?

mighty9245 on 17 Dec 2019

I`ve tested this on xrender and glx with same result

akemrir on 17 Dec 2019

i mean, do you launch picom with --experimental-backends? probably no tho

mighty9245 on 17 Dec 2019

Nope. I don't use experimental backends option,

akemrir on 17 Dec 2019

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.

mighty9245 on 18 Dec 2019

Listen to fun part. I tried with kitty and it worked.
But for xfce4-terminal not, check please this one exactly.

akemrir on 18 Dec 2019

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'"
];

mighty9245 on 18 Dec 2019

So it looks like problem with qtile not compositor.

akemrir on 18 Dec 2019

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.

mighty9245 on 18 Dec 2019

So let's do that way. After that check eventually I will ping qtile programmers.

akemrir on 18 Dec 2019

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.

akemrir on 1 Jan 2020

I observe the same behavior in my set up:

freebsd 12.1
picom v7.5
cwm

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

2020-02-17-084333_1366x768_scrot

correct border color in xterm and pcmanfm

2020-02-17-084439_1366x768_scrot

linhvng on 17 Feb 2020

@akemrir sorry, with the setup in your original post, what does it look like if you don't run picom?

yshui on 10 Mar 2020

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

akemrir on 11 Mar 2020

hey, frame-opacity is known to be broken on some setups, but i assume without it you can't achieve your idea?

mighty9245 on 11 Mar 2020

@mighty9245 yes, exactly

akemrir on 11 Mar 2020

@akemrir thanks. can i have a screenshot for reference?

yshui on 11 Mar 2020

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?
2020-03-12-023502_1920x1848_scrot

firefox has invalid border color with webrender enabled:
2020-03-12-023518_1920x1848_scrot

alacritty has the same issue
2020-03-12-023530_1920x1848_scrot

firefox has correct border color with webrender disabled and frame-opacity=1
2020-03-12-023735_1920x1848_scrot

without picom:
2020-03-12-023547_1920x1848_scrot
2020-03-12-023554_1920x1848_scrot

linhvng on 12 Mar 2020

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

akemrir on 12 Mar 2020

I think I might know what the problem is.

Looks like the RGB color is not properly pre-multiplied with the alpha value.

yshui on 12 Mar 2020

🎉1 😄1

@akemrir BTW, does --experimental-backends have the same problem?

yshui on 12 Mar 2020

@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 on 13 Mar 2020

@akemrir I think I fixed this problem in --experimental-backends, still investigating the old backends.

yshui on 17 Mar 2020

👍1

@linhvng Can you capture a trace of picom showing the invalid border color, with apitrace ?

yshui on 17 Mar 2020

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

2020-03-17-174104_1366x768_scrot

linhvng on 17 Mar 2020

@linhvng ah, perhaps you are using the xrender backend? Does the glx backend work?

yshui on 18 Mar 2020

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

2020-03-18-082352_1366x768_scrot

linhvng on 18 Mar 2020

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

yshui on 18 Mar 2020

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 on 18 Mar 2020

@linhvng The border still looks transparent even when you set --frame-opacity=1?

yshui on 22 Mar 2020

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.

yshui on 22 Mar 2020

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

yshui on 22 Mar 2020

@linhvng The border still looks transparent even when you set --frame-opacity=1?

yessir

linhvng on 22 Mar 2020

@yshui These problems are from qtile wm.

akemrir on 24 Mar 2020

@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 on 25 Mar 2020

👍2

@yshui thanks for help, I am putting your conclusions here
https://github.com/qtile/qtile/issues/692

akemrir on 26 Mar 2020

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.

a-vrma on 16 Apr 2020

I`ve tested awesomewm, and there this problem is not present.
So this is related to WM directly.

akemrir on 16 Apr 2020

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.

a-vrma on 16 Apr 2020

👍1

Thanks!! I was having this problem for a long time already.
Great patch! (well.. workaround)