Arch Linux
Vega 64
Two monitors (Primary: 1920x1080 144Hz, Secondary: 1280x1024 75Hz)
xf86-video-amdgpu 19.0.1-1
mesa-aco-git
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: Radeon RX Vega (VEGA10, DRM 3.30.0, 5.1.16-arch1-1-ARCH, LLVM 8.0.1) (0x687f)
Version: 19.3.0
Accelerated: yes
Video memory: 8176MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 7951 MB, largest block: 7951 MB
VBO free aux. memory - total: 8125 MB, largest block: 8125 MB
Texture free memory - total: 7951 MB, largest block: 7951 MB
Texture free aux. memory - total: 8125 MB, largest block: 8125 MB
Renderbuffer free memory - total: 7951 MB, largest block: 7951 MB
Renderbuffer free aux. memory - total: 8125 MB, largest block: 8125 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 8176 MB
Total available memory: 16352 MB
Currently available dedicated video memory: 7951 MB
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.30.0, 5.1.16-arch1-1-ARCH, LLVM 8.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.0-devel (git-f2bed9b344)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: no-error
OpenGL core profile profile mask: core profile
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-f2bed9b344)
OpenGL shading language version string: 4.50
OpenGL context flags: no-error
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.0-devel (git-f2bed9b344)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
bspwm
Bisected to 426043baa7f4e2e8dc40d682d0e7d79222d7b570
backend="xrender";
opacity-rule = ["20:class_g = 'Bspwm' && class_i = 'presel_feedback'"];
fading = true;
fade-in-step = 0.1;
fade-out-step = 0.1;
wintypes:
{
tooltip =
{
fade = true;
shadow = false;
opacity = 0.85;
focus = false;
};
};
(Also tried backend="glx")
https://gfycat.com/unsungthiscoati
blockbar clears the bar here
This only happens on my primary monitor. If I run Steam on my second monitor, the bar on my primary monitor is still affected.
I've just found that it also happens when I run xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" $(xdo id -n blockbar), which moves blockbar below all other windows, except the root window. If the bar on my secondary monitor is lower, I get the clearing problem on the bar on my primary monitor. If the bar on my primary monitor is lower, I don't get problem with either bar.
Managed to reproduce it on my laptop which has an integrated Vega GPU by running xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" $wid_of_bar_on_second_monitor
it's possible that the transparency detection in wrong for windows without a wm frame. i will investigate.
@sambazley sorry, i hadn't had much time to investigate this.
can you record a apitrace of this happening?
compton.trace.xz.gz
Sorry for the .xz.gz. Github doesn't allow .xz files, and .gz alone was too big to upload.
I can definitely see compton is doing something out of the ordinary here. Besides the not clearing issue, the text of the bar doesn't render quite right either, it gets thicker and thicker over time.
Can you record an apitrace of compton running with --log-level=trace? You might want to redirect the output since trace log level generates tons of output.
I think the text getting thicker is due to the antialiasing rendering over the previous render calls. I'll run apitrace when I get home.
@sambazley you are right. but it's caused by compton, not because the bar itself has a bug.
Yes, but surely that's the same bug? The alpha is adding with each render.
To clarify my previous message, the text in the desktop selector does not become thicker because the bar is rendering behind it. 
The text grows elsewhere on the bar because I've disabled the background rendering to emphasise the bug.
I start blockbar and compton with
compton --config ~/.config/compton/config &
~/blockbar/blockbar &
xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" $(xdo id -n blockbar)
However, it seems like blockbar usually starts before compton. If I add a sleep 0.5 between the first two lines, the bug is triggered consistently. If I start blockbar first, sleep 0.5, then start compton, the bug is consistently not triggered.
@sambazley what do you mean by "disabled the background rendering" ?
Just setting the alpha to 0.
@sambazley I pushed a fix attempt to next, can you test it?
picom.tar.xz.gz
The bug is still happening.
@sambazley I added extra debug prints. Can you run the debug-233 branch, and attach the log and trace here?
Thanks.
win_client_has_alpha returns true for blockbar windows. However, changing that function to return true for all windows causes blockbar to render correctly. Disabling blockbar's tray (either by modifying blockbar's source, or by killing all processes with a tray icon) also seems to cause blockbar to render correctly.