I'm probably going to move blurring into i3lock-color soonish

[PandorasFox]

I've been playing with adding in a native, c-based gaussian blur effect to i3lock-color when I do the next feature enhancement (I'll likely be adding some clock options and font options """soon""" as well). I recently found this when dicking around on github during lectures, which has given me some ideas on how to implement gaussian blurring.

This will offer a few advantages over blurring a screenshot:

• there'll be less of a delay before you can call i3lock, although there might be a bit of a delay before i3lock actually shows
• * (I don't think this'll be too much of an issue, since i3lock now has the "locking" intermediary display, so it'll just show that briefly before it displays the blurred image)
• the blurring will probably be a bit more performant and will run with less overhead

Eventually I may add an option to grab the current screenbuffer (and require blurring), or have the blur option take the screenshot (the logic being that if you want a blurred image, you should preblur it and save that - so using the blur option will implicitly mean you want a screenshot.)

One of the downsides of this is that jesus christ, I'm running out of single character options and the options for invoking this are getting complicated. I might also have to look into setting a config file (maybe under XDG_CONFIG_HOME/i3/lock.cfg?) to simplify things.

Thoughts?

(Also, I never realized there was an aur package for my fork; I completely forgot to ever make one, but it's nice to have someone else maintaining packaging it)

[PandorasFox]

I've got a clock branch where I'm adding support to have a clock display inside the lock indicator. I'll be tweaking it some to play more nicely with my stuff and I'll update the code some to just be a bit cleaner in general, but that's done already.

Next on the list are custom string time formatters, as well as (hopefully) custom fonts, followed by adding a blur option, a screenshot option, and then finally a config file. Lemme know if you have any thoughts on this or anything you'd like that'll make your script easier to work with.

I'd definitely much rather have some blurring functionality so that i3lock will grab and lock as soon as possible, and then blur after it's seized and update the image buffer with the blurred image once blurring is finished.

One of my friends had the idea of displaying the initial image, then iteratively blurring the image and updating the framebuffer with that at each iteration. While I think that would look cool, there's a tradeoff because of increased CPU usage (and users that have a large blur radius set would be waiting for a while, unless I do some intelligent stepping/set number of steps from radius=0 to radius=n).

I think there's some potential for making this look really nice.

[meskarune]

wow, I'm really excited about these improvements. Clock and background blur both sound awesome! I agree that it would be better to lock the screen first and updated the image sent with a blur. It would be much faster and more robust.

I was able to speed the blur up by resizing the image down to 20%, blurring it and resizing up again to 500%. Maybe you could do something like that? It helps with increasing the processing speed when people have really large screens or multiple monitors.

[PandorasFox]

I'll keep that in mind. Resizing will probably be pretty weird in C and I'll be trying to find a solution that pulls in a minimal number of dependencies to keep building easy (or I'll add a compiler flag/make option, most likely).

I'm still sorta partial to the slow iterative blurring, since at least for desktop users, CPU usage won't be as much of a concern. I may end up implementing both since one will just be a for loop, and the other will just be some sort of quick resize/blur/scale.

I'm working on fleshing out the clock stuff right now (I've got it mostly working right now; I just need to go and tweak some of the font configs/allow custom time format strings.)

I'm also tempted to redo the longopts to be, well, less long, but I'll leave everything backwards-compatible for now. I think blurring support will be enough of a change that breaking some of the CL options (timeout -> T, inside -> I, and then shorter longopts for the colors (or just --ver-color, --inside-ver-color, etc, with --ver-color being the default for the *ver* colors, and then the others overriding and being loaded in next.

There's been a lot of things I've been wanting to do to clean up i3lock and make it less clunky, and either a config file or a better CLI are on the horizon, but I'm not sure which one I'll go with. Probably both.

[PandorasFox]

I've gotten preliminary blurring in my i3lock fork. It's not perfect and will be getting quite a bit of work done on it over the next week or so (ideally I'll get this done this weekend, because the alternative would be working on actual classwork).

I'd appreciate it if feedback on implementation on blurring is given here for anyone else who reads this (although I doubt anyone other than meskarune will read this).

[PandorasFox]

Just realized something belatedly: I have no idea how this is really going to help you in the long run, since I'll need to add support for overlaying text on the lockscreen as well. The lock icon can probably be handled as well, but I'll have to see.

I'll figure something out sooner or later, but I've got high hopes for the step blurring and how it'll look.

[PandorasFox]

I think when I get blurring sorted out (thanks to that guy who's looking into it for me) I'll see about either compiling another binary to use exclusively for blurring, or just add a CLI switch, or something.

[PandorasFox]

I have no idea how this is really going to help you in the long run, since I'll need to add support for overlaying text on the lockscreen as well. The lock icon can probably be handled as well, but I'll have to see.

I think I could probably rig up something with -I to allow passing in an arbitrary number of images, which'll then be layered over the pixmap that gets blurred. (Or at least, allow passing in one image... you get the idea).

If I get that working I'll be pretty happy. Hopefully I'll have time to work on this soon.

[PandorasFox]

Blurring is in the mainline, so this is done. Other discussion will be in #6