FR: With -B, display the unblurred screenshot while waiting for the blurring process to finish

[wlritchi]

This issue is a....

[ ] Bug
[x] Other kind of issue (Feature request)

Current Behavior

With -B, i3lock takes a screenshot, blurs it, and then shows the blurred image. This creates a noticeable delay, which can be exaggerated further for testing by setting the parameter to a high value.

Desired Behavior

Option for i3lock to initially render with the original, unblurred screenshot. Blur the image in another thread, and switch to the blurred image when complete.

My use case: I'm abusing i3lock --no-verify (with yubikey-touch-detector) to show a full-screen prompt when I need to touch the button on my Yubikey; thus, i3lock's slow start can be jarring while I am actively using the machine (though the current behaviour does not actually slow down my workflow, since the workflow is waiting on me to interact with the Yubikey at that point anyway).

Perhaps more common use case: if someone returns to their machine after xautolock or similar has launched i3lock, but before i3lock has actually rendered, they could encounter a very frustrating lock-after-started-typing situation; reducing the time between "lock screen triggered" and "lock screen rendered" means less frequent violation of user expectations.

Reproduction Instructions

$ time i3lock -B20 --no-verify # press enter as soon as i3lock renders, or hold it down
real    0m6.869s
user    0m6.772s
sys     0m0.046s

Environment

Output of i3lock --version:

i3lock: version 2.13.c.4 © 2010 Michael Stapelberg, © 2015 Cassandra Fox, © 2021 Raymond Li

Where'd you get i3lock-color from?

[x] AUR package (i3lock-color)
[ ] Built from source yourself
[ ] Other (Please describe in detail)

[Raymo111]

I've gotten several bug reports about it lagging, so I think this is worth a shot. We could show the unblurred screenshot, with a warning text saying blurring..., or we could investigate whether it'd be possible to blur progressively, starting with a smaller sigmas.

[SafwanLjd]

It actually goes beyond just simply displaying the un-blurred screenshot, it is not displaying anything at all, what you see is not a screenshot, it's your system at work, and if you're fast enough you could kill the i3lock process to prevent it from locking! it'd be awesome if there was an option to specify an image that appears while blurring, or if it just displayed the wallpaper, or even a simple black screen, anything is better than what we have now!

[Raymo111]

Interesting. What's the behaviour when you specify both an image AND the blur option?

[SafwanLjd]

Interesting. What's the behaviour when you specify both an image AND the blur option?

It ignores the blur option and displays the image, I presume that's because of some if-else behavior in the code and the -i option happened to come before the -B option

[Raymo111]

Interesting. I can probably enable some kind of overloading to display the image before blurring it. Or I think a better option would be to blur with a tiny radius first, draw and lock, then reblur with the desired radius.

I'll take a look at this over Christmas break, and hopefully get the couple open PRs merged as well.

[SafwanLjd]

@Raymo111 For now I solved the issue by not using the --blur option, and setting --color to #00000000 (to make transparent); And since I'm running picom anyway, I can make it blur the (now transparent) background with some edits in my picom.conf

Example picom.conf

blur-method = "kawase";
blur-kern = "3x3box";
blur-strength = 5;

# this line disables blur on all other programs that aren't the lock screen
blur-background-exclude = [ "class_g != 'i3lock'" ];

It looks exactly the same but without the annoying (and insecure?) delay.

But this fix only makes sense if you're already using a compositor that supports blur.

[Raymo111]

@SafwanLjd Why does picom blur faster than i3lock-color?

[SafwanLjd]

@Raymo111 I'm not sure, but probably because i3lock-color takes a screenshot, edits it (probably using ImageMagick), and only then sets it as a background, while picom is actually displaying the actual windows and is just adding a blur effect on top

[JezerM]

Exactly, i3-lock takes an screenshot and blurs the image by traveling every pixel of the image. However, this blur process is slow, and gets slower over time.

A few months ago, I tried to overcome this problem by showing the image on screen and refreshing it when the blur it's done. But, for some reason, drawing the image on screen affected the information being used on the blur process, which made it never blur or "segmentation fault".

Perhaps, these solutions could be done:

• Copy the cairo_surface_t obtained on "screenshot" and blur this copy in another thread. (Didn't find a way to copy a Cairo surface, though)
• Change the blur method. (Didn't find a nice solution for Cairo, either)

[SafwanLjd]

Well, this means that blurring using picom is arguably better, since it allows you to see the changes in the background, unlike blurring natively with i3lock-color

Blurring by setting --color=#00000000 and using picom

Blurring by using --blur=5

[Raymo111]

arguably better

Some people might want a fixed blurred screenshot, so it's not necessarily better, it's more a different option.

[SafwanLjd]

arguably better

Some people might want a fixed blurred screenshot, so it's not necessarily better, it's more a different option.

I guess you're right, but it's still a better option speed-wise anyway

Anyway, I hope you guys figure it out! I would've contributed myself if I knew a little bit more C... Maybe someday

[Raymo111]

I would've contributed myself if I knew a little bit more C... Maybe someday

Always an option to learn on the job (aka while contributing code to fix this) :)

[alanswanson]

Having just started using i3lock-color today and having the same confusion as to why it was so slow a generating a blurred screenshot, I noticed the that compile logs show debug is enabled by default in the configure.ac and -O0 is appended after any user CFLAGS meaning no optimisation.

Rebuilt with ./configure --disable-debug and it now takes fraction of a second. Debug should be disabled by default!

[Raymo111]

Having just started using i3lock-color today and having the same confusion as to why it was so slow a generating a blurred screenshot, I noticed the that compile logs show debug is enabled by default in the configure.ac and -O0 is appended after any user CFLAGS meaning no optimisation.

Rebuilt with ./configure --disable-debug and it now takes fraction of a second. Debug should be disabled by default!

@alanswanson I'm not able to see a difference between the two, is there anything else you're doing?

[JezerM]

I actually see a big difference without debug enabled:

$ time i3lock -B20 --no-verify # Default i3lock-color
i3lock -B20 --no-verify  25.32s user 0.08s system 98% cpu 25.714 total

$ time ./i3lock -B20 --no-verify # Compiled with `./configure --disable-debug`
./i3lock -B20 --no-verify  3.25s user 0.04s system 97% cpu 3.377 total

[alanswanson]

No, that was the only change I made to make a previously 4s pause on a 2560x1440 screen less than 0.3s for a blur radius of 5.

My CFLAGS are "-O2 -march=znver1 -ftree-vectorize -fvect-cost-model=cheap" so vectorisation might additionally help but gcc12 should pass __SSE2__ define for the blur_simd.c usage but didn't check that.

[Raymo111]

Where are you setting CFLAGS? I'm on a 3840x2160 screen and I have this:

$ time i3lock -B20 --no-verify # Default

real    0m7.889s
user    0m7.761s
sys     0m0.067s
$ time ./build/i3lock -B20 --no-verify # Compiled with `./configure --disable-debug`

real    0m7.914s
user    0m7.800s
sys     0m0.067s

[alanswanson]

Through a Gentoo ebuild but would be just the same as passing in the env.

[Raymo111]

I have a similar setup for CFLAGS (Arch makepkg config) and I'm still getting the same thing. Not sure what the difference is.

[alanswanson]

Do you use clang? With GCC if multiple -On options are defined then it uses the last one but it's not clear what Clang does - maybe uses the highest optimisation defined? Otherwise no idea (except that debug should still be disabled by default regardless).

[Raymo111]

Do you use clang? With GCC if multiple -On options are defined then it uses the last one but it's not clear what Clang does - maybe uses the highest optimisation defined? Otherwise no idea (except that debug should still be disabled by default regardless).

No, I use GCC. I'm fine with disabling debug by default, it just doesn't solve this issue for me.

[Raymo111]

Done in 37eecf2.