Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lag #159

Open
sidequestboy opened this issue May 14, 2020 · 18 comments
Open

Lag #159

sidequestboy opened this issue May 14, 2020 · 18 comments

Comments

@sidequestboy
Copy link

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
@Raymo111
Copy link
Owner

@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.

@sidequestboy
Copy link
Author

i3lock

I still get this behaviour on 9ada23e - note how it doesn't display 28 in this gif

@Raymo111
Copy link
Owner

hmm. I'm not sure what's wrong. I certainly don't get any jumping

@sidequestboy
Copy link
Author

sidequestboy commented May 15, 2020

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.

@Raymo111
Copy link
Owner

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?

@sidequestboy
Copy link
Author

sidequestboy commented May 15, 2020

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.

@Raymo111
Copy link
Owner

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?

@sidequestboy
Copy link
Author

bspwm with compton tryone fork.

@sidequestboy
Copy link
Author

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.

@Raymo111
Copy link
Owner

But is there any lag over time? (Or just at launch)

@sidequestboy
Copy link
Author

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.

@Raymo111
Copy link
Owner

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?

@Raymo111 Raymo111 reopened this May 15, 2020
@Raymo111 Raymo111 changed the title --clock display skips seconds Lag May 15, 2020
@sidequestboy
Copy link
Author

sidequestboy commented May 15, 2020

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"?

@Raymo111
Copy link
Owner

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.

@sidequestboy
Copy link
Author

sidequestboy commented May 19, 2020

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 [email protected]
Date: Fri Dec 8 02:29:05 2017 -0500

make 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.

@Raymo111
Copy link
Owner

Interesting. @Jameh I've got no idea why that's a security risk. @PandorasFox wanna weigh in on this?

@PandorasFox
Copy link

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

@Raymo111
Copy link
Owner

Raymo111 commented May 19, 2020

Ahh. Thanks. @Jameh you should be ok using --redraw-thread then for now :)

I'll optimize this some day based on fox's suggestions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants