yshui / picom

A lightweight compositor for X11 with animation support
https://picom.app/
Other
4.13k stars 589 forks source link

Invalid border color on xfce4-terminal, sakura #285

Open akemrir opened 4 years ago

akemrir commented 4 years ago

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

absolutelynothelix commented 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.

akemrir commented 4 years ago

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.

absolutelynothelix commented 4 years ago

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?

akemrir commented 4 years ago

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

akemrir commented 4 years ago

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

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

absolutelynothelix commented 4 years ago

are you using experimental backends?

akemrir commented 4 years ago

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

absolutelynothelix commented 4 years ago

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

akemrir commented 4 years ago

Nope. I don't use experimental backends option,

absolutelynothelix commented 4 years ago

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

akemrir commented 4 years ago

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

absolutelynothelix commented 4 years ago

can't reproduce running xfce4-terminal too. image

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'"
];
akemrir commented 4 years ago

So it looks like problem with qtile not compositor.

absolutelynothelix commented 4 years ago

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.

akemrir commented 4 years ago

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

akemrir commented 4 years ago

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.

linhvng commented 4 years ago

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

2020-02-17-084333_1366x768_scrot

correct border color in xterm and pcmanfm

2020-02-17-084439_1366x768_scrot

yshui commented 4 years ago

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

akemrir commented 4 years ago

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

absolutelynothelix commented 4 years ago

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

akemrir commented 4 years ago

@mighty9245 yes, exactly

yshui commented 4 years ago

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

linhvng commented 4 years ago

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

akemrir commented 4 years ago

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

yshui commented 4 years ago

I think I might know what the problem is.

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

yshui commented 4 years ago

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

akemrir commented 4 years ago

@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.
yshui commented 4 years ago

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

yshui commented 4 years ago

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

linhvng commented 4 years ago

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

yshui commented 4 years ago

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

linhvng commented 4 years ago

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

yshui commented 4 years ago

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

linhvng commented 4 years ago

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:

yshui commented 4 years ago

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

yshui commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

yessir

akemrir commented 4 years ago

@yshui These problems are from qtile wm.

yshui commented 4 years ago

@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

akemrir commented 4 years ago

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

averms commented 4 years ago

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.

akemrir commented 4 years ago

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

averms commented 4 years ago

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.

kooskaspers commented 4 years ago

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

kbc8090 commented 4 years ago

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.

averms commented 4 years ago

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.

averms commented 4 years ago

@yshui as far as I'm aware this is a wm problem so you can close the issue if you want.