25% cpu and slow screen writing after suspend, when using -b option

[bitshiftnetau]

Issues after suspend when using -b (run as daemon) option as detailed in this manual: https://jlk.fjfi.cvut.cz/arch/manpages/man/compton.1

and the ArchWiki: https://wiki.archlinux.org/index.php/Compton

Platform

Arch Linux
kernel: 4.19.32-1-lts
OpenBox: 3.6.1

GPU, drivers, and screen setup

Nvidia Quadro 3000M
driver: nvidia-340xx-lts
version 340.107

xf86-video-fbdev 0.5.0-1
xf86-video-vesa 2.4.0-2

glxinfo: command not found

Environment

Bare openbox with Tilda, Tint2, conky, compton and desktop apps. UEFI boot.

Compton version

v6.2

$ compton --diagnostics
[ 04/06/19 08:49:43.583 parse_config_libconfig WARN ] vsync option will take a boolean from now on. "opengl" is interpreted as "true" for compatibility, but this will stop working soon
[ 04/06/19 08:49:43.583 parse_config_libconfig WARN ] glx-swap-method has been deprecated since v6, your setting "undefined" should be removed.
Version: v6.2

Extensions:

• Shape: Yes
• XRandR: Yes
• Present: Present

Misc:

• Use Overlay: Yes
• Config file used: /home/access/.config/compton.conf

Compton configuration:

same issue without or without config file

### Steps of reproduction
1. Launch compton from Openbox autostart file with -b option 
2. run systemctl suspend 

### Expected behavior
Normal rendering

### Current Behavior
25% cpu usage
slow, line-by-line screen writing

[bitshiftnetau]

I've fixed this problem by launching compton with a trailing ambersand (&) to signify running as background process.

This looks like a known issue with certain drivers, I will inform the ArchWiki and instruct the use of ambersand in place of the -b flag if this error presents for other users.

[yshui]

@bitshiftnetau It would be very helpful if you can figure out what is actually using the CPU. You can use perf for that. If you want to try remember to build compton with debug info.

[heavykisiel]

I was able to reproduce it on arch:

OS: Arch Linux x86_64
Kernel: 6.7.3-arch1-1
WM: awesome
CPU: 11th Gen Intel i5-11400F (12) @ 4.400GHz
GPU: NVIDIA Geforce RTX 3050

my picom --diagnostics
`Version: vgit-fc1d1

Extensions:

• Shape: Yes
• RandR: Yes
• Present: Present

Drivers (inaccurate):

NVIDIA, modesetting

Backend: glx

• Driver vendors:
• GLX: NVIDIA Corporation
• GL: NVIDIA Corporation
• GL renderer: NVIDIA GeForce RTX 3050/PCIe/SSE2

Backend: egl

• Driver vendors:
• EGL: NVIDIA
• GL: NVIDIA Corporation
• GL renderer: NVIDIA GeForce RTX 3050/PCIe/SSE2`

I was using picom -b on startup and my CPU usage varies between 0.1% - 0.3% and takes around 80mb.
When I run systemctl suspend and get out of suspension picom process goes into crazy 11-16 CPU Usage and take twice RAM as before plus temperatures goes high. Unfortunately changing it to picom & not helping and problem persist. After running picom --log-level debug and getting out of suspension I have massive spam of prompts like this:

[ 02/06/2024 15:24:04.885 check_render_finish DEBUG ] Last render did not complete during vblank, msc: 0
[ 02/06/2024 15:24:04.885 check_render_finish DEBUG ] Last render did not complete during vblank, msc: 0
[ 02/06/2024 15:24:04.885 check_render_finish DEBUG ] Last render did not complete during vblank, msc: 0

till I kill process. After reloading my window manager it goes to normal CPU usage. So right now solution that comes to my mind is to write script and run it to kill picom, then run systemctl suspend and run picom -b again, but its kinda doesnt solves software problem.

[absolutelynothelix]

@heavykisiel, try picom built from the latest commit in the next branch. if your issue is the one i'm thinking about, it should be already fixed there.

[yshui]

@heavykisiel your issue seems to be #1168

i will also close this issue as it's very old. if the original problem is still reproducible on latest picom, please open a new issue.