Lag
sidequestboy opened this issue · comments
I'm submitting a…
[X] Bug [ ] Feature Request [ ] Other (Please describe in detail)
Current Behavior
i3lock --clock seconds don't update at regular intervals, and sometimes skip seconds.
Expected Behavior
Seconds should update on screen at the correct intervals and not skip.
Reproduction Instructions
Run
i3lock --clock
and watch the seconds for half a minute, notice how they skip.
Environment
Output of i3lock --version:
i3lock: version 2.12.c.1 (2020-03-10, branch "tags/2.12.c.1") © 2010 Michael Stapelberg, © 2015 Cassandra Fox
@Jameh please update to the latest version (2.12.c.3) and see if the problem still exists. I just watched the clock for 75 seconds and there was no sign of skipping.
I still get this behaviour on 9ada23e - note how it doesn't display 28 in this gif
hmm. I'm not sure what's wrong. I certainly don't get any jumping
So, using --refresh-rate 0.1 seems to make the issue much less obvious, (it won't full-out skip numbers) but it still seems like it's got an uncanny lag.
I honestly don't know what the issue is. If you restart your computer and just run startx i3lock --clock --noverify from a shell, does the lag continue?
If I log out and in to a tty and modify my xinitrc to end with
i3lock --clock --nofork
instead of my window manager, it seems pretty well-behaved, and doesn't skip full numbers. I still feel like one of the first few seconds lags though.
Interesting. I also have that issue, but that's just lag at the beginning. I feel like the seconds skipping issue is something with your compositor. What wm/de are you on?
bspwm with compton tryone fork.
I just tested without compton running, I still get a skipped number and a noticable lag in the first few seconds while launching from bspwm.
But is there any lag over time? (Or just at launch)
The skipped numbers happen kind of irregularly, and about every 2 minutes maybe?
I just watched for 2 minutes with a metronome at 60bpm without compton running, I noticed a lag in the 2nd second, then pretty regular, I felt like it was pretty much in sync with the metronome for 2 minutes, then it displayed the same number twice in a row and continued, then skipped a number about 5 seconds later.
Hahahahaha I'm reopening this issue just cause you sat there with a metronome. Talk about dedicated. Suggestions as to what might be a generic lag issue?
So, I found the option --redraw-thread:
Starts a separate thread for redrawing the screen. Potentially worse for security, but makes the bar indicator still do its usual periodic redraws when PAM is authenticating.
And I don't notice any jankyness when run with that (watched it for a minute lol) - do you have any idea why this is "worse for security"?
Hmm, interesting. I have no idea. Maybe have a look at the code and history to see who added it? Maybe that commit will have more info. Also that's probably an upstream thing, so you'll wanna check i3/i3lock too.
So, it's commits 3edfb79 and 59cdccb which add the render thread option, which was after the fork, and i3/i3lock doesn't have either the --redraw-thread option or the --clock option, so the issue is specific to this fork. But yeah, the --redraw-thread option seems to hide the issue.
The security concern seems to be about the render thread crashing
commit 59cdccb
Author: Pandora Pandora@techfo.xyz
Date: Fri Dec 8 02:29:05 2017 -0500make render thread optional
theoretical potential security concerns; no use unless using bar and you care... I hammered pretty hard on my kb for a while to try and see if it's possible to configure it poorly and get the render thread to crash, but to no avail.
Interesting. @Jameh I've got no idea why that's a security risk. @PandorasFox wanna weigh in on this?
so, primarily - I never really tested it that much and I'm not entirely confident in its safety (e.g. I probably clowned something up in a subtle way that can cause all threads to crash/exit). It's probably fine in general, though.
iirc the reason for the slight accruing lag over time is caused by a single redraw taking longer than a second. there's a lot of ways that this could potentially be optimized (e.g. identify the region of the screen that has to be redrawn, organize the different canvases better so that it's faster to composite them together, etc) but frankly I never had the time to sit down and refactor all that
Ahh. Thanks. @Jameh you should be ok using --redraw-thread then for now :)
I'll optimize this some day based on fox's suggestions