Closed tgbugs closed 7 months ago
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment, or this issue will be closed in 30 days.
To my knowledge this is still a bug that has not been resolved.
Yep. Just confirmed that it is still happening on conky 1.13.1 compiled 2022-11-20 for Linux x86_64. Note to self: can check with conky -c ~/.conkyrc-example
.
This sounds super annoying, I will see if I can figure out what's going on.
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment, or this issue will be closed in 30 days.
This issue was closed because it has been stalled for 30 days with no activity.
This is likely still and issue and should probably remain open.
Issue
Conky causes a massive slowdown hitting quadratic behavior when the window created by
own_window = true
is too wide. The quadratic behavior seems to be based on the total area of the window being rendered once a threshold in the width of the window is crossed.This behavior effectively causes the whole window manager to lag for long periods of time when running without a compositor, or when running with a compositor the result is that the window manager will hitch every time the conky window is redrawn.
As a point of amusement/horror. This issue in combination with an asterisk in an unquoted bash
${VAR}
and having many files in${HOME}
(the runtime path for conky) turns out to have been the root cause of the last 8 months (to the day) of my life being filled with the creeping insanity that initially a slack window with a new notification, and eventually any window with an*
in the title would immediately cause my whole system to start lagging uncontrollably. The problem would go away when I cleared files out of${HOME}
only to return, apparently at random, but now in retrospect it was when enough new files accumulated to trigger this behavior in conky.Information
Linux 5.11.6-gentoo x86_64 Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz GenuineIntel GNU/Linux
conky 1.12.1 compiled 2021-03-19 for Linux x86_64
The config below should be sufficint to tigger the issue, in the event that it does not, it may be due to some difference in the size of the virtual desktop. The xrandr output for my setup is.
The xft font and verdana:size=7 are used to cause a strong non-linearity in performance when crossing from 5456 to 5457 in the padding below. The behavior can be reproduced using the default font.