compton lags on intel card

[ghost]

Platform

Archlinux

GPU, drivers, and screen setup

• xf86-video-intel-1:2.99.917+863+g6afed33b, two monitors configured side-by-side with xrandr
• mesa-19.0.0-1-x86_64

ie

xrandr --output eDP1 --scale 1x1 --auto --pos 5120x0 \
       --output DP1 --scale 2x2 --auto --pos 0x0 --primary

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  (0x5917)
    Version: 19.0.0
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 19.0.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

i3

Compton version

$ compton --diagnostics
**Version:** v6

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: /home/tya99/.config/compton/compton.conf

Compton configuration:

# Compton configuration
inactive-opacity = 0.85;
inactive-dim = 0.1;
inactive-dim-fixed = true

# See https://github.com/chjj/compton/issues/182 for some examples
# on compton rule setting.

# The i3lock rule is needed to stop the screenlocker being transparent.
focus-exclude = ["class_g = 'mpv'",
                 "name *?= 'libreoffice'",
                 "name = 'i3lock'",
                 "class_g = 'Firefox'"];

# Unused settings
#menu-opacity = 0.8;
#fading = true;
#fade-in-step = 0.009;
#fade-out-step = 0.009;
#blur-background = true;
opacity-rule = ["99:class_g = 'mpv'",
                "99:class_g = 'Firefox'"];
shadow-exclude = ["class_g = 'mpv'",
                "class_g = 'Firefox'"];
fade-exclude = ["class_g = 'mpv'",
                "class_g = 'Firefox'"];

Steps of reproduction

I used to run

exec --no-startup-id compton -b --vsync opengl --config ~/.config/compton/compton.conf 

However it seems now the --vsync opengl option as of Compton 6 causes an error.

compton doesn't accept positional arguments.

It wasn't apparent to me what the replacement should have be. If you spot anything else you think is wrong there please do tell.

I have also noticed everything seems really laggy in compton 6 as opposed to 5.1, assuming I start it with

compton --vsync --config ~/.config/compton/compton.conf

[yshui]

--vsync doesn't take argument anymore.

The lag part is probably a duplication of #139

Wait, you are using the xrender backend. The vsync change should have no effect on the lag. I'm not sure what you mean. I tried your config on an Intel card, and cannot reproduce the lag.

Also, it's recommended that you use the glx backend

[ghost]

I think the lag is unrelated. When I just run without -b --vsync opengl, on compton 5.1 everything is fine as well. The lag only happens with 6.0. I specifically have a Intel UHD Graphics 620.

[yshui]

@tya99 I think the command line option issue is resolved. I change the title of this issue to make it about the lag.

[ghost]

Do you think this could be related to #139 ? If there's anything you want me to try, to get to the bottom of this I'm ready to help.

[yshui]

@tya99 Well first I want to understand what do you mean by "everything seems really laggy"

[ghost]

@tya99 Well first I want to understand what do you mean by "everything seems really laggy"

Scrolling in Firefox, context menus opening etc selection. Same for Thunar as well. Generally everything appears sluggish. glxgears also gives off real poor frames:

225 frames in 5.0 seconds = 44.614 FPS
199 frames in 5.0 seconds = 39.798 FPS
198 frames in 5.1 seconds = 39.051 FPS
211 frames in 5.0 seconds = 42.127 FPS

Where as with compton 5.1

307 frames in 5.0 seconds = 61.328 FPS
300 frames in 5.0 seconds = 59.846 FPS
300 frames in 5.0 seconds = 59.862 FPS
300 frames in 5.0 seconds = 59.860 FPS

And no compositor:

342 frames in 5.0 seconds = 68.368 FPS
300 frames in 5.0 seconds = 59.851 FPS
300 frames in 5.0 seconds = 59.859 FPS
300 frames in 5.0 seconds = 59.812 FPS
300 frames in 5.0 seconds = 59.907 FPS
300 frames in 5.0 seconds = 59.862 FPS
300 frames in 5.0 seconds = 59.862 FPS

[yshui]

Can you try using the glx backend? compton --backend glx.

Also, try compton --use-damage.

[ghost]

With --use-damage I think things might have been marginally better, but the gears still were a bit choppy, not nice and smooth like they were in 5.1

253 frames in 5.0 seconds = 50.460 FPS
282 frames in 5.0 seconds = 56.185 FPS
262 frames in 5.0 seconds = 51.991 FPS
245 frames in 5.0 seconds = 48.832 FPS
274 frames in 5.0 seconds = 54.773 FPS
246 frames in 5.0 seconds = 48.983 FPS
210 frames in 5.0 seconds = 41.924 FPS
220 frames in 5.1 seconds = 43.523 FPS
229 frames in 5.0 seconds = 45.567 FPS
219 frames in 5.0 seconds = 43.561 FPS
260 frames in 5.0 seconds = 51.981 FPS
266 frames in 5.0 seconds = 53.045 FPS

When I set --backend glx things were pretty horrible still.

198 frames in 5.0 seconds = 39.380 FPS
190 frames in 5.0 seconds = 37.815 FPS
192 frames in 5.0 seconds = 38.367 FPS
189 frames in 5.0 seconds = 37.533 FPS
204 frames in 5.0 seconds = 40.664 FPS
201 frames in 5.0 seconds = 40.130 FPS
192 frames in 5.0 seconds = 38.191 FPS
197 frames in 5.0 seconds = 39.373 FPS
199 frames in 5.0 seconds = 39.498 FPS

I'm not sure if glxgears is the best way to test this? I don't really know a lot about this area (graphics not my thing) so it was a way I thought I could benchmark.

There certainly seems to be a correlation between the "smoothness" of the gears, frame-rate and what works nicely elsewhere though.

[yshui]

Hmm, not quite sure what changed to cause this.

If you got time, maybe you could do a git bisect.

[ghost]

Hmm, not quite sure what changed to cause this.

If you got time, maybe you could do a git bisect.

Can do that, is there a particular commit you want me to check between?

[yshui]

@tya99 Between 5.1 and 6 I guess? Since you said 5.1 is fine.

Thanks

[ghost]

@tya99 Between 5.1 and 6 I guess? Since you said 5.1 is fine.

Thanks

Yeah I just read the man for bisect. I thought it would be harder

e109bee looks good, there's a bunch that are only produce a black screen for me. Trying to narrow it down to the one that makes performance go to shit.

[ghost]

98d8e84 is the first one that actually runs. The frames have dropped significantly there.

264 frames in 5.0 seconds = 52.669 FPS
269 frames in 5.0 seconds = 53.629 FPS
272 frames in 5.0 seconds = 54.191 FPS
268 frames in 5.0 seconds = 53.481 FPS
269 frames in 5.0 seconds = 53.317 FPS

It's not the worst but it's certainly not smooth like it was when it was 300 frames.

[yshui]

BTW, I forgot to ask. Are you running these tests with or without vsync enabled? If you don't set vsync in command line or the config file, vsync is disabled.

Also, please make sure you do the tests with nothing else running.

[ghost]

That first test ie v6 release

with --vsync

157 frames in 5.0 seconds = 31.272 FPS
170 frames in 5.0 seconds = 33.817 FPS
170 frames in 5.0 seconds = 33.979 FPS
167 frames in 5.0 seconds = 33.219 FPS
159 frames in 5.0 seconds = 31.721 FPS
161 frames in 5.0 seconds = 32.016 FPS

Ooops I might have forgotten. Using v6

with --vsync --use-damage

233 frames in 5.0 seconds = 46.461 FPS
245 frames in 5.0 seconds = 48.618 FPS
237 frames in 5.0 seconds = 47.094 FPS
247 frames in 5.0 seconds = 49.393 FPS
228 frames in 5.0 seconds = 45.356 FPS
236 frames in 5.0 seconds = 47.001 FPS

and with --vsync --backend glx

213 frames in 5.0 seconds = 42.562 FPS
214 frames in 5.0 seconds = 42.400 FPS
200 frames in 5.0 seconds = 39.901 FPS
200 frames in 5.0 seconds = 39.805 FPS
196 frames in 5.0 seconds = 39.016 FPS
196 frames in 5.0 seconds = 39.002 FPS

e109bee looks good

--vsync opengl

302 frames in 5.0 seconds = 60.346 FPS
297 frames in 5.0 seconds = 59.258 FPS
300 frames in 5.0 seconds = 59.861 FPS
299 frames in 5.0 seconds = 59.658 FPS
300 frames in 5.0 seconds = 59.867 FPS
300 frames in 5.0 seconds = 59.855 FPS

98d8e84 not so good

--vsync opengl

249 frames in 5.0 seconds = 49.601 FPS
255 frames in 5.0 seconds = 50.922 FPS
265 frames in 5.0 seconds = 52.764 FPS
273 frames in 5.0 seconds = 54.543 FPS
261 frames in 5.0 seconds = 52.144 FPS
269 frames in 5.0 seconds = 53.780 FPS

Then it seems things drop dramatically at

dd240d0

--vsync

208 frames in 5.0 seconds = 41.492 FPS
211 frames in 5.1 seconds = 41.676 FPS
204 frames in 5.0 seconds = 40.503 FPS
183 frames in 5.0 seconds = 36.533 FPS
213 frames in 5.0 seconds = 42.396 FPS
189 frames in 5.0 seconds = 37.656 FPS

[ghost]

Also, please make sure you do the tests with nothing else running.

I had Firefox and termite, but that's all, oh and i3, i3status etc.

[ghost]

Also, please make sure you do the tests with nothing else running.

I had Firefox and termite, but that's all, oh and i3, i3status etc.

Tried it again with Firefox closed, and yeah still same issue, confirmed at all points mentioned in comment #142 (comment) same kinds of values.

[ghost]

So I'm starting to think there might be two different issues. Ie everything is fine at e109bee then through to 98d8e84 I can't actually get compton to work, all I get is a black screen with mouse pointer. At this point performance has dropped considerably.

Finally at dd240d0 it drops further again, which is the same as the final v6 release.

[yshui]

Can you test v5.1 with --vsync opengl-swc?

[ghost]

Can you test v5.1 with --vsync opengl-swc?

Yeah, the frame rate is awful.

$ compton --vsync opengl-swc --backend glx

210 frames in 5.0 seconds = 41.794 FPS
201 frames in 5.0 seconds = 39.854 FPS
205 frames in 5.0 seconds = 40.936 FPS
212 frames in 5.0 seconds = 42.180 FPS
196 frames in 5.0 seconds = 38.978 FPS

[yshui]

@tya99 So, that is the problem then. Try just disable vsync.

[ghost]

@tya99 So, that is the problem then. Try just disable vsync.

If I do that on 5.1 it works okay:

compton --vsync none --config ~/.config/compton/compton.conf

290 frames in 5.0 seconds = 57.868 FPS
300 frames in 5.0 seconds = 59.859 FPS
300 frames in 5.0 seconds = 59.858 FPS
300 frames in 5.0 seconds = 59.859 FPS

Do you just not specify --vsync in v6 to not use it? because if I do that I get terrible frames:

./build/src/compton

184 frames in 5.0 seconds = 36.740 FPS
205 frames in 5.0 seconds = 40.910 FPS
200 frames in 5.0 seconds = 39.725 FPS
204 frames in 5.0 seconds = 40.557 FPS
197 frames in 5.0 seconds = 39.233 FPS

[yshui]

@tya99 If you didn't set vsync to true in your config file, then this is pretty interesting.

Can you do a bisect with vsync disabled all the way? If you have the time, of course.

[ghost]

@tya99 If you didn't set vsync to true in your config file, then this is pretty interesting.
Can you do a bisect with vsync disabled all the way? If you have the time, of course.

Sure, you can see my config (in my first post) has not got vsync set. I will now re-run the tests without vsync for comparison.

So compton v6 ie 3bf86b3

231 frames in 5.0 seconds = 46.198 FPS
218 frames in 5.0 seconds = 43.513 FPS
192 frames in 5.0 seconds = 38.362 FPS
186 frames in 5.0 seconds = 37.111 FPS
189 frames in 5.0 seconds = 37.689 FPS

./build/src/compton --use-damage

268 frames in 5.0 seconds = 53.308 FPS
285 frames in 5.0 seconds = 56.503 FPS
274 frames in 5.0 seconds = 54.718 FPS
286 frames in 5.0 seconds = 57.145 FPS
260 frames in 5.0 seconds = 51.862 FPS
252 frames in 5.0 seconds = 50.359 FPS

./build/src/compton --backend glx

200 frames in 5.0 seconds = 39.868 FPS
197 frames in 5.0 seconds = 39.334 FPS
192 frames in 5.0 seconds = 38.342 FPS
200 frames in 5.0 seconds = 39.835 FPS
188 frames in 5.0 seconds = 37.453 FPS
192 frames in 5.0 seconds = 38.351 FPS

Now looking at commit e109bee

things seem to be great as they were in the above tests, nice and smooth.

./build/src/compton

300 frames in 5.0 seconds = 59.835 FPS
300 frames in 5.0 seconds = 59.862 FPS
300 frames in 5.0 seconds = 59.857 FPS
299 frames in 5.0 seconds = 59.660 FPS
300 frames in 5.0 seconds = 59.858 FPS
300 frames in 5.0 seconds = 59.861 FPS

Now at commit: 98d8e84

./build/src/compton 

Those frames are not so good, and it looks jerky.

281 frames in 5.0 seconds = 56.168 FPS
275 frames in 5.0 seconds = 54.720 FPS
271 frames in 5.0 seconds = 53.712 FPS
219 frames in 5.0 seconds = 43.494 FPS
257 frames in 5.0 seconds = 51.037 FPS
295 frames in 5.0 seconds = 58.739 FPS

I was able to get commit 709065d running, but not any earlier in that portion in the middle because when running compton I'd just get a black screen.

288 frames in 5.0 seconds = 57.479 FPS
282 frames in 5.0 seconds = 56.343 FPS
296 frames in 5.0 seconds = 58.888 FPS
289 frames in 5.0 seconds = 57.594 FPS
290 frames in 5.0 seconds = 57.991 FPS

At commit: dd240d0 Things are much worse as they were above, just writing in vim is painful. Wow.

212 frames in 5.0 seconds = 42.144 FPS
153 frames in 5.0 seconds = 30.545 FPS
164 frames in 5.1 seconds = 32.342 FPS
174 frames in 5.0 seconds = 34.623 FPS
222 frames in 5.1 seconds = 43.865 FPS
227 frames in 5.0 seconds = 45.215 FPS

So I decided to try one commit after e109bee (the good one)

Black screen, so there goes that idea, so it seems to be black screening in the same place, and performance seems to be decreasing in the same places.

[ghost]

Interesting.... I tried compton 6.2 with --use-damage and it seems we're back to smooth frames per second around 300 like I used to get. --vsync and --backend glx is still terrible though.

Should I be doing these bisects on master or next? Up until now I have been doing them on master.

[ghost]

I should also note that v6.1rc2 was better than before 3bf86b3

as I was getting

275 frames in 5.0 seconds = 54.846 FPS
289 frames in 5.0 seconds = 57.715 FPS
287 frames in 5.0 seconds = 57.083 FPS
286 frames in 5.1 seconds = 56.426 FPS
279 frames in 5.0 seconds = 55.750 FPS
287 frames in 5.0 seconds = 56.914 FPS

but still not as good as what 6.2 final is, ie ff85c11

By the way, should I be getting normal frames like 300 with --vsync and/or --backend glx, which is better etc. I don't know a lot about this area.

[ghost]

I should also mention that even with v5.2 and --backend glx I only got:

189 frames in 5.0 seconds = 37.698 FPS
190 frames in 5.0 seconds = 37.871 FPS
193 frames in 5.0 seconds = 38.566 FPS
192 frames in 5.0 seconds = 38.230 FPS
190 frames in 5.0 seconds = 37.807 FPS

I seem to remember that being better on my NVIDIA card (another machine).

However on that release compton --vsync opengl or opengl-oml gave me:

302 frames in 5.0 seconds = 60.211 FPS
298 frames in 5.0 seconds = 59.465 FPS
300 frames in 5.0 seconds = 59.862 FPS
299 frames in 5.0 seconds = 59.658 FPS
299 frames in 5.0 seconds = 59.659 FPS
300 frames in 5.0 seconds = 59.863 FPS
300 frames in 5.0 seconds = 59.859 FPS

So with 6.2 I settled on compton --vsync --use-damage. If there's anything else you want me to test I will do so!

[ciampolo]

This is caused by fast repainting of windows. If you play an mpv video it will lag miserably. See tryone144/compton#5

Kwin does not have this problem so could look there how to solve it. It seems Kwin just excludes OpenGL windows from compositing (at least partially).

With Kwin (with full blur, transparency effects multiple videos and a game running all visible and moving/resizing windows) I get full FPS/Frames without any single lag or tearing.

Also Kwin uses some "tricks" appearently. When moving a Dolphin window by dragging its toolbar while mpv video is running, it will also lag miserably (even worse than compton). When using the mod+mouse hotkey or just dragging the window from its titlebar it stays at 60fps regardless how busy the screen actually is.

[ciampolo]

To put the update I posted in the other fork:
For some reason that for the life of me I cannot understand it now works very fluent nearly as much as kwin. Kwin has the edge still though that is because Kwin does, as already said, some very intelligent tricks during repainting.

I don't know why I get full FPS now (even with multiple openGl applications running and moving) but I get 60fps at glxgears.

Nvidia proprietary and Gentoo here.

[polaroidkidd]

Unfortunately I'm seeing the same issues.
I'm running picom with picom --experimental-backends --config ~/.config/picom/picom.conf -b

I have shadows and Dual-kawase aktivated.

The frame rate drops happen only with the glx-backend, not with the xrender backend (but that doesn't support the blur). I've tried various combinations of having vsync active/inactive and use-damage active/inactive. Generly the frame rate is marginally better when vsync is disabled and use-damage, but no where near enough to make a comfortable usage.

I would simply opt for the xrender backend, but that doesn't have the Dual-kawase blur implemented (also, the shadows leave traces when I'm dragging the window around).

I've tried various versions from this thread as well and I'm currently on the next branch.

At first I thought it had something to do with my drivers, as I'm using the display-port driver, but switching it out for the intel drivers made no difference in performance. I've included the config files as well just in case I oversaw some glaring defect:

/usr/share/X11/xorg.conf.d/20-intel.conf

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "TearFree"    "true"
EndSection

/usr/share/X11/xorg.conf.d/20-evdidevice.conf

Section "OutputClass"
	Identifier "DisplayLink"
	MatchDriver "evdi"
	Driver "modesetting"
	Option  "AccelMethod" "none"
EndSection

GLX Info

glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917)
    Version: 20.0.8
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.8
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Picom Diagnostics

picom  --diagnostics         
[ 10/11/20 09:25:47.345 get_cfg WARN ] Dual-kawase blur is not implemented by the legacy backends, you must use the `experimental-backends` option.
[ 10/11/20 09:25:47.454 init_render WARN ] Old backends only support blur method "kernel". Your blur setting will not be applied
**Version:** vgit-248bf

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: No
 (Another compositor is already running)
* Config file used: /home/dle/.config/picom/picom.conf

### Drivers (inaccurate):

modesetting

Picom Config

#################################
#             Shadows           #
#################################


# shadow = false
shadow = true;

# The blur radius for shadows, in pixels. (defaults to 12)
# shadow-radius = 12
shadow-radius = 5;

# The opacity of shadows. (0.0 - 1.0, defaults to 0.75)
# shadow-opacity = .9;

# The left offset for shadows, in pixels. (defaults to -15)
# shadow-offset-x = -15
shadow-offset-x = 5;

# The top offset for shadows, in pixels. (defaults to -15)
# shadow-offset-y = -15
shadow-offset-y = 5;

# Avoid drawing shadows on dock/panel windows. This option is deprecated,
# you should use the *wintypes* option in your config file instead.
#
# no-dock-shadow = false

# Don't draw shadows on drag-and-drop windows. This option is deprecated, 
# you should use the *wintypes* option in your config file instead.
#
# no-dnd-shadow = false

# Red color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-red = 0

# Green color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-green = 0

# Blue color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-blue = 0

# Do not paint shadows on shaped windows. Note shaped windows 
# here means windows setting its shape through X Shape extension. 
# Those using ARGB background is beyond our control. 
# Deprecated, use 
#   shadow-exclude = 'bounding_shaped'
# or 
#   shadow-exclude = 'bounding_shaped && !rounded_corners'
# instead.
#
# shadow-ignore-shaped = ''

# Specify a list of conditions of windows that should have no shadow.
#
# examples:
#   shadow-exclude = "n:e:Notification";
#

# Sets the opacity 0 <= shadow-opacity <= 1
shadow-opacity = 0.15;
# shadow-exclude = []
shadow-exclude = [
  "name = 'Notification'",
  "class_g = 'Conky'",
  "class_g ?= 'Notify-osd'",
  "class_g = 'Cairo-clock'",
  "_GTK_FRAME_EXTENTS@:c",
  "!I3_FLOATING_WINDOW@:c && !class_g = 'Rofi' && !class_g = 'dmenu'"
];

# Specify a X geometry that describes the region in which shadow should not
# be painted in, such as a dock window region. Use 
#    shadow-exclude-reg = "x10+0+0"
# for example, if the 10 pixels on the bottom of the screen should not have shadows painted on.
#
# shadow-exclude-reg = "" 

# Crop shadow of a window fully on a particular Xinerama screen to the screen.
# xinerama-shadow-crop = false


#################################
#           Fading              #
#################################


# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
# fading = false
fading = false;

# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.03;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.03;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
# fade-delta = 10

# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []

# Do not fade on window open/close.
# no-fading-openclose = false

# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false


#################################
#   Transparency / Opacity      #
#################################


# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
# inactive-opacity = 1
#inactive-opacity = 0.8;

# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
# frame-opacity = 1.0
frame-opacity = 1;

# Default opacity for dropdown menus and popup menus. (0.0 - 1.0, defaults to 1.0)
# menu-opacity = 1.0

# Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows.
# inactive-opacity-override = true
inactive-opacity-override = false;

# Default opacity for active windows. (0.0 - 1.0, defaults to 1.0)
# active-opacity = 1.0

# Dim inactive windows. (0.0 - 1.0, defaults to 0.0)
# inactive-dim = 0.0

# Specify a list of conditions of windows that should always be considered focused.
# focus-exclude = []
focus-exclude = [ "class_g = 'Cairo-clock'" ];

# Use fixed inactive dim value, instead of adjusting according to window opacity.
# inactive-dim-fixed = 1.0

# Specify a list of opacity rules, in the format `PERCENT:PATTERN`, 
# like `50:name *= "Firefox"`. picom-trans is recommended over this. 
# Note we don't make any guarantee about possible conflicts with other 
# programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows.
# example:
#    opacity-rule = [ "80:class_g = 'URxvt'" ];
#
# opacity-rule = []


#################################
#     Background-Blurring       #
#################################


# Parameters for background blurring, see the *BLUR* section for more information.
blur-method = "dual_kawase"; 

# blur-size = 12
#
# blur-deviation = false

# Blur background of semi-transparent / ARGB windows. 
# Bad in performance, with driver-dependent behavior. 
# The name of the switch may change without prior notifications.
#
blur-background = true;

# Blur background of windows when the window frame is not opaque. 
# Implies:
#    blur-background 
# Bad in performance, with driver-dependent behavior. The name may change.
#
# blur-background-frame = false


# Use fixed blur strength rather than adjusting according to window opacity.
# blur-background-fixed = false


# Specify the blur convolution kernel, with the following format:
# example:
#   blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1";
#
# blur-kern = ''
# blur-kern = "3x3box";


# Exclude conditions for background blur.
# blur-background-exclude = []
blur-background-exclude = [
  "window_type = 'dock'",
  "window_type = 'desktop'",
  "_GTK_FRAME_EXTENTS@:c"
];

#################################
#       General Settings        #
#################################

# Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers.
# daemon = false

# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = 'glx'
backend = "glx";

# Enable/disable VSync.
# vsync = false
vsync = true;


# Enable remote control via D-Bus. See the *D-BUS API* section below for more details.
# dbus = false

# Try to detect WM windows (a non-override-redirect window with no 
# child that has 'WM_STATE') and mark them as active.
#
# mark-wmwin-focused = false
mark-wmwin-focused = true;

# Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused.
# mark-ovredir-focused = false
mark-ovredir-focused = true;

# Try to detect windows with rounded corners and don't consider them 
# shaped windows. The accuracy is not very high, unfortunately.
#
# detect-rounded-corners = false
detect-rounded-corners = false;

# Detect '_NET_WM_OPACITY' on client windows, useful for window managers
# not passing '_NET_WM_OPACITY' of client windows to frame windows.
#
# detect-client-opacity = false
detect-client-opacity = false;

# Specify refresh rate of the screen. If not specified or 0, picom will 
# try detecting this with X RandR extension.
#
# refresh-rate = 60
refresh-rate = 0

# Limit picom to repaint at most once every 1 / 'refresh_rate' second to 
# boost performance. This should not be used with 
#   vsync drm/opengl/opengl-oml
# as they essentially does sw-opti's job already, 
# unless you wish to specify a lower refresh rate than the actual value.
#
# sw-opti = 

# Use EWMH '_NET_ACTIVE_WINDOW' to determine currently focused window, 
# rather than listening to 'FocusIn'/'FocusOut' event. Might have more accuracy, 
# provided that the WM supports it.
#
# use-ewmh-active-win = false

# Unredirect all windows if a full-screen opaque window is detected, 
# to maximize performance for full-screen windows. Known to cause flickering 
# when redirecting/unredirecting windows. paint-on-overlay may make the flickering less obvious.
#
#  unredir-if-possible = true

# Delay before unredirecting the window, in milliseconds. Defaults to 0.
# unredir-if-possible-delay = 0

# Conditions of windows that shouldn't be considered full-screen for unredirecting screen.
# unredir-if-possible-exclude = []

# Use 'WM_TRANSIENT_FOR' to group windows, and consider windows 
# in the same group focused at the same time.
#
# detect-transient = false
detect-transient = true

# Use 'WM_CLIENT_LEADER' to group windows, and consider windows in the same 
# group focused at the same time. 'WM_TRANSIENT_FOR' has higher priority if 
# detect-transient is enabled, too.
#
# detect-client-leader = false
detect-client-leader = true

# Resize damaged region by a specific number of pixels. 
# A positive value enlarges it while a negative one shrinks it. 
# If the value is positive, those additional pixels will not be actually painted 
# to screen, only used in blur calculation, and such. (Due to technical limitations, 
# with use-damage, those pixels will still be incorrectly painted to screen.) 
# Primarily used to fix the line corruption issues of blur, 
# in which case you should use the blur radius value here 
# (e.g. with a 3x3 kernel, you should use `--resize-damage 1`, 
# with a 5x5 one you use `--resize-damage 2`, and so on). 
# May or may not work with *--glx-no-stencil*. Shrinking doesn't function correctly.
#
# resize-damage = 1

# Specify a list of conditions of windows that should be painted with inverted color. 
# Resource-hogging, and is not well tested.
#
# invert-color-include = []

# GLX backend: Avoid using stencil buffer, useful if you don't have a stencil buffer. 
# Might cause incorrect opacity when rendering transparent content (but never 
# practically happened) and may not work with blur-background. 
# My tests show a 15% performance boost. Recommended.
#
# glx-no-stencil = false

# GLX backend: Avoid rebinding pixmap on window damage. 
# Probably could improve performance on rapid window content changes, 
# but is known to break things on some drivers (LLVMpipe, xf86-video-intel, etc.).
# Recommended if it works.
#
# glx-no-rebind-pixmap = true

# Disable the use of damage information. 
# This cause the whole screen to be redrawn everytime, instead of the part of the screen
# has actually changed. Potentially degrades the performance, but might fix some artifacts.
# The opposing option is use-damage
#
# no-use-damage = false
use-damage = true

# Use X Sync fence to sync clients' draw calls, to make sure all draw 
# calls are finished before picom starts drawing. Needed on nvidia-drivers 
# with GLX backend for some users.
#
# xrender-sync-fence = false

# GLX backend: Use specified GLSL fragment shader for rendering window contents. 
# See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl` 
# in the source tree for examples.
#
# glx-fshader-win = ''

# Force all windows to be painted with blending. Useful if you 
# have a glx-fshader-win that could turn opaque pixels transparent.
#
# force-win-blend = false

# Do not use EWMH to detect fullscreen windows. 
# Reverts to checking if a window is fullscreen based only on its size and coordinates.
#
# no-ewmh-fullscreen = false

# Dimming bright windows so their brightness doesn't exceed this set value. 
# Brightness of a window is estimated by averaging all pixels in the window, 
# so this could comes with a performance hit. 
# Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0)
#
# max-brightness = 1.0

# Make transparent windows clip other windows like non-transparent windows do,
# instead of blending on top of them.
#
# transparent-clipping = false

# Set the log level. Possible values are:
#  "trace", "debug", "info", "warn", "error"
# in increasing level of importance. Case doesn't matter. 
# If using the "TRACE" log level, it's better to log into a file 
# using *--log-file*, since it can generate a huge stream of logs.
#
# log-level = "debug"
log-level = "warn";

# Set the log file.
# If *--log-file* is never specified, logs will be written to stderr. 
# Otherwise, logs will to written to the given file, though some of the early 
# logs might still be written to the stderr. 
# When setting this option from the config file, it is recommended to use an absolute path.
#
# log-file = '/path/to/your/log/file'

# Show all X errors (for debugging)
# show-all-xerrors = false

# Write process ID to a file.
# write-pid-path = '/path/to/your/log/file'

# Window type settings
# 
# 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard: 
#     "unknown", "desktop", "dock", "toolbar", "menu", "utility", 
#     "splash", "dialog", "normal", "dropdown_menu", "popup_menu", 
#     "tooltip", "notification", "combo", and "dnd".
# 
# Following per window-type options are available: ::
# 
#   fade, shadow:::
#     Controls window-type-specific shadow and fade settings.
# 
#   opacity:::
#     Controls default opacity of the window type.
# 
#   focus:::
#     Controls whether the window of this type is to be always considered focused. 
#     (By default, all window types except "normal" and "dialog" has this on.)
# 
#   full-shadow:::
#     Controls whether shadow is drawn under the parts of the window that you 
#     normally won't be able to see. Useful when the window has parts of it 
#     transparent, and you want shadows in those areas.
# 
#   redir-ignore:::
#     Controls whether this type of windows should cause screen to become 
#     redirected again after been unredirected. If you have unredir-if-possible
#     set, and doesn't want certain window to cause unnecessary screen redirection, 
#     you can set this to `true`.
#
# wintypes:
# {
#   tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; full-shadow = false; };
#   dock = { shadow = false; }
#   dnd = { shadow = false; }
#   popup_menu = { opacity = 0.1; }
#   dropdown_menu = { opacity = 0.8; }
# };

[polaroidkidd]

I should specify that this only happens when I'm moving a floating window. Otherwise the framerate (per glxgears) hovers around 60fps