i3lock extremely slow after latest update #128
Comments
|
I'm having similar problems when compton is on. When it's off, everything works correctly, but when it's on, the locker doesn't completely blank my screen until a key is pressed, the X process starts using a bunch of CPU, and keypresses are slow, like you described. Quick guess: It might be this commit: 80d4452 At least, reverting this commit fixed it for me. |
|
There's been a couple of people who've poked on my fork's issues about compositors, so I guess I'll chime in here (maybe I should make a separate issue? Not sure if these should fall under this or not). A few people are having problems with compositors not properly dealing with i3lock in a few ways - sometimes the compositor doesn't clean up after i3lock or something, and sometimes compositors cause flickering and stuff in i3lock. All of their issues have been present in xsecurelock, so whatever's going on, it's probably something wholly with the compositor, and not a locking program. Personally, I've had no issues using compton (with a fairly minimal config): i3lock works fine on top of it, notifications don't show up, and there's no graphical issues during or after. Apparently that's not the case across the board, though. I've put a |
|
I've been messing with my compton config, and I've noticed that the cause for this problem is compton's fading option. When that's disabled, the screen is properly blanked. However, even with a completely "clean" compton config, the X process starts using a bunch of CPU, and there's the input lag. |
|
@sandsmark Is this issue related to your #96? |
|
Same issue for me these past days... takes up to 6 seconds before removing the lock screen Verified that killing compton fixes the issue. |
|
what compositors, versions of the compositors, and mesa drivers do you all use? |
|
@sandsmark |
|
The same problem happens with xcompmgr. Versions: |
|
Same here, xcompmgr 1.1.7, mesa 17.1.2, xorg-drivers 1.19 (modesetting ddx on intel). |
|
Can anyone here please test again with the current HEAD? We just merged the reversal of #96 and I assume this fixes it. |
|
Looks good. Snappy as ever. Thanks. |
|
Thanks for the feedback! |
|
Works now! |
|
still super slow for me, built from 3009ab4 |
|
@hossbeast In that case please open a new issue and bisect where the problem starts. |
|
I'm having this issue on Ubuntu 17.10 with i3-gaps. Not sure where to go from here... |
2022-06-21 i3lock 2.14.1 • unlock indicator: display only caps lock and num lock, not all modifiers like shift (which can leak information about your password to bystanders) 2022-05-28 i3lock 2.14 • Change default background color to #a3a3a3 See i3/i3lock#300 for extensive discussion and rationale for this change. • Recommend using xss-lock to start i3lock in the README and i3lock.1 man page. xss-lock is the best way to ensure your screen truly is locked before your computer suspends. • Display modifier key warning before unlocking, too, not just on failed attempts like before. • Switch build system from autotools to meson. 2020-10-27 i3lock 2.13 • Throw error when trying to start on Wayland • Use explicit_bzero() where available, not just on OpenBSD • avoid pixmap allocations in the redraw path • make --debug output go to stderr • unlock_indicator.c: fix build failure against gcc-10 • fix: call pam_end in cleanup in main, not in event loop • set _NET_WM_BYPASS_COMPOSITOR hint to avoid flickering 2019-07-21 i3lock 2.12 • remove stray \n from error messages • capitalize unlock indicator contents • set WM_CLASS property • reference modifier as “Super”, not “Win” • add --raw option to read image as raw bytes 2018-10-18 i3lock 2.11.1 • Fix dist tarball by including I3LOCK_VERSION 2018-10-10 i3lock 2.11 • Switch to autotools • Display an error when backspace is pressed without any input • Print an error when a non-PNG file is opened (i3lock only supports PNG files) (Thanks eplanet) • Don’t unnecessarily check the xcb_connect return value, it is known never to be NULL (Thanks SegFault42) • Fix memory leak when grabbing fails (Thanks karulont) • Respect Xft.dpi for determining the unlock indicator’s scale factor • Discard pending password verification attempts when a new password is entered (Thanks layus) 2017-11-25 i3lock 2.10 • Only use -lpam when not on OpenBSD (Thanks Kaashif) • locale: treat empty string same as unset (Thanks Ran) • Fix overwrite of getopt optind (Thanks jakob) • Immediately hide the unlock indicator after ESC / C-u (Thanks Orestis) • Measure wall-clock time instead of CPU time for “locking” indicator. • SetInputFocus to the i3lock window to force-close context menus • Use RandR for learning about attached monitors 2017-06-21 i3lock 2.9.1 • Fix version number mechanism (for --version) • Revert the fix for composited notifications, as it causes more issues than it solves: i3/i3lock#130 i3/i3lock#128 2017-05-26 i3lock 2.9 • i3lock.1: use signal names without SIG prefix • Removed obsolete inactivity timeout • Added version files for release tarball. • Set font face • Automatically unlock (without having to press <Enter>) one attempt which was entered while authenticating • Stop leaking the image_path dup • Displaying locking message when grabbing the pointer/keyboard • Display error message when locking failed • Add Enter on C-m • Change input slices to be exactly pi/3 in size instead of slightly more • Fix covering of composited notifications using the XComposite extension • Remove last traces of DPMS • Use bsd_auth(3) instead of PAM on OpenBSD • Restore intended behaviour and don't use mlock(2) on OpenBSD.
I am using i3lock (version: 2.9-1~~xenial1) from the http://debian.sur5r.net/i3 repo and it appears to be extremely slow after the latest update (I've rebooted just to be sure). I am using it on Ubuntu 16.04.
it's slow:
The text was updated successfully, but these errors were encountered: