brndnmtthws / conky

Light-weight system monitor for X, Wayland (sort of), and other things, too
https://conky.cc
GNU General Public License v3.0
7.28k stars 621 forks source link

[Bug]: conky doesn't properly clear draw buffer on large time step #942

Open beta-tester opened 4 years ago

beta-tester commented 4 years ago

Issue

i have a Raspberry Pi, that does not have an internal battery buffered RTC clock. so it happens, that first the fake-hwclock takes the time of the last shutdown and receiving the correct time will take some time (from internet, GPS or other external sources). when conky is already running and the system time makes a bigger step, conky will screw up... e.g.: its transparent background will turn solid black and multiple elements will be caotically overwritten. restarting sudo killall -SIGUSR1 conky will bring the display back to normal.

beta-tester commented 4 years ago

Screenshot from 2020-02-13 16-01-23 Screenshot from 2020-02-13 16-02-13

github-actions[bot] commented 1 year 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.

github-actions[bot] commented 1 year ago

This issue was closed because it has been stalled for 30 days with no activity.

bi4k8 commented 1 year ago

It seems likely that there's something wrong with Conky's logic around its update interval and which clock (monotonic, etc.) it relies on. This might be a bit of a pain to write a test case for, but also seems worth fixing.

beta-tester commented 1 year ago

i am not sure if this was the configuration i used back then: https://gist.github.com/beta-tester/efa3b636703f0a61a0be7a2a2623f97f

Caellian commented 7 months ago

The buffer seems to not get cleared, which is weird given that the code related to clearing X11 buffer doesn't depend on time - i.e. it should happen before every render.

In main_loop we pass "time until next update" while trying to select display buffer file here as timeout value.

And the other (last) place in the main_loop is here, where we "wait before next draw" in order to respect redraw interval.

The only other thing that comes to mind is X11 discarding

Caellian commented 7 months ago

I self assigned this issue because I'd like to add eager rendering (no delay) as well. Someone else can take over this issue if they want to and I didn't open a PR in the meantime.

Caellian commented 1 month ago

Marked with low priority as it's a very niche issue. Unassigned myself because it's hard to tell when I'll have time to deal with it and it's less pressing than Wayland support.

Some additional thoughts: maybe this has to do with XDBE code and not even conky? It's hard to tell at this point because this issue is relatively old, OP probably no longer has the same setup around.

I suggest letting this issue be closed if it gets stale again. I can reopen it someone has the same problem as OP did 4 years ago.