hecate cantus

I believe that's a general problem with some sorts of hardware-accelerated blurs and it's one of the tradeoffs with speed vs accuracy, but I might be misremembering.

Actually, one this note, my fork of i3lock will have a blurring option, so that'll be moved out of this script and will vastly speed up the locking. You can...

I've no idea yet how ffmpeg's blurring will compare to [what's pending](https://github.com/sebastian-frysztak/i3lock-color/tree/fast-blur) for my i3lock fork (I have a feeling like ffmpeg's code will be a bit more polished, but...

Perhaps, but if we're already grabbing the screen, it's pretty trivial to use xcb to just capture it and blur it. While ffmpeg can do gaussian blurring pretty quickly, I'll...

Here's the timings from what I'm seeing with i3lock blurring vs ffmpeg: ``` arcana@archana:~/i3lock-color$ time (scrot in.png && ffmpeg -loglevel quiet -y -i in.png -vf "gblur=sigma=8" out.png && ./i3lock -i...

Oh yeah, definitely, but the script has always used at least some of the features specific to a fork (primarily being the custom colors); originally, it relied on a fork...

There's blurring in the mainline of i3lock-color, so if you want to tentatively start using that, it should work fine. So far for overlaying text/etc you'll have to pad out...

oof, fontconfig stuff I imagine that it's probably something related to fontconfig 2.13, since that's been... buggy, at times.

Worst case, we can reuse the code in xinerama.h to reliably get the same output as i3lock. So far, it seems to be in left to right order, I think...

I could possibly do something like `i3lock --displays` or something to dump the different outputs, so that there's sorta not an external dep