The script is slow

[simlevesque]

Hi, I was wondering if it was just me or is the script really slow ?

[Sweets]

It uses ImageMagick's convert tool to modify images, twice at that. The script isn't asynchronous, because if out was you would have broken or missing components (some perhaps disabling the program altogether, at least from just a glance). Really the only thing you can do is deal with it being "slow" (although it could be much slower), or even find a different script to use.

Also, if this sounds rude, apologies, it isn't meant to.

[meskarune]

It takes about 2.5s on my netbook to run. I resize the image down, blur it and then resize back up, which helped, but yeah, it still takes a few seconds.

You can speed it up a bit more by changing the blur setting from -filter Gaussian -resize 50% -define filter:sigma=4.5 -resize 200% to -filter Gaussian -resize 50% -define filter:sigma=2.5 -resize 200% but then the background isn't as blurred.

You could also skip doing a blur altogether and pixelate the background instead with scale.

I might play around with resizing even smaller than 50%, perhaps 30% would be better, especially for larger screen sizes. But I am also open to suggestions to help improve the speed.

The speed issue is partly just the nature of the image editing that is happening. Try doing a blur on an image with gimp or using a filter in gimp to see, it just takes some time to do. For my use, I use xautolock to lock automatically after 5 min so I don't really notice the initial run speed as I'm generally away from the computer anyways.

[meskarune]

I just tested with 30% resize down and 333.33% resize up, and it didn't significantly improve the speed for me. It went from like 2.5s to 2.3s. Then I changed the sigma to 2.5 and the speed was like 2.2s. It's not really a huge improvement, but I could try with these settings if people don't mind the change in quality.

screenshots:

regular script

resize changed to 30% and sigma 2.5

[simlevesque]

@Coilest

"Really the only thing you can do is deal with it being "slow" (although it could be much slower), or even find a different script to use."

Or I could help you fix it... Maybe you like slow things, it's just not my thing.

---

Ok, here's where I'm at :

• It's slow on my end because I have multiple monitors.
• The crunching into a 1 pixel block looks like the most expensive operation.
• The only part that needs to be crunched is the center monitor since it is the only one which will have text on it.
• You need every monitors to be blurred, but you only need to crunch the middle screen so there should be two scrot (scrot is not an expensive operation).
• From my observations, it seems like crunching a jpg is faster than crunching a png. The screen shot to be crunched should be in .jpg.
• It's even faster if you set the quality to one (-q=1) for the jpg scrot since it's quicker to crunch a jpg which is lossy (that's how you make a thumbnail).

I'll try to send you a pull request ASAP !

[simlevesque]

Some more :

• You can't tell scrot to take a picture of a single monitor, you'd need another step and it would add time.
• While reading the man page for scrot, I discovered a feature that could speed up the process : the -t argument which creates a thumbnail at the same time as it shoots the picture. The thumbnail can be crunched faster since it's already smaller.

[simlevesque]

My best try at fixing the script takes one more second than meskarune/i3lock-fancy. 11 second for my version and 10 second for yours. Three monitors, Imagemagick with OpenCL & OpenMP.

By the way : if you wanna compare performance between various imagemagick operations, add the --bench argument.

[meskarune]

@simlevesque I was thinking of switching to maim and had a similar idea to yours. Basically just grab the center bit of the screen where the text will be to determine color instead of the whole screen. A 300px square area in the center would probably cover it. Maim can grab a selection of the screen as well as take screenshots.

https://github.com/naelstrof/maim

The downside is maim isn't as popularly available as scrot in various linux distros, but then i3lock-color isn't either I suppose.

Thanks for the tip about --bench it will come in useful :)

[pid1]

I am using maim in my fork, so I can play around with --localize. I will need to figure out a way to get relative locations, though, instead of hard-coding for a certain screen resolution.

[carnager]

I use this in teiler: https://github.com/DaveDavenport/xininfo

carnager@caprica ~ > xininfo -mon-size
2560 1440
carnager@caprica ~ > xininfo -active-mon
0

[insanebits]

What if we would hide problem from the user by first applying some transitional background (greyish filter on top of screenshot for example) so we can show locked screen ASAP. And then do calculations in the background. And once finished switch to the "nice" background.

The biggest problem for me is: when I hit lock shortcut it seems like nothing happened, and after ~10s it locks down. I wouldn't care if it would not be that good looking while script renders background. As long as I know my system is already locked and I can leave my computer instead of waiting 10s to vertify it's locked.

What do you guys think?

[meskarune]

@insanebits could you try the current script and let me know how slow it is for you? I have changed some things since this issue was opened that have helped the speed for me significantly.

[insanebits]

Nice to hear about it. On my system latest version takes about ~2.5s which is acceptable. Awesome job! Will test it tomorrow on my work machine which is a bit older and see how it performs.