search

yvbbrjdr / i3lock-fancy-rapid

A faster implementation of i3lock-fancy.
BSD 3-Clause "New" or "Revised" License
144 stars 20 forks source link

This is slower than i3lock-blur #11

Open sgraf812 opened 4 years ago

sgraf812 commented 4 years ago

I'm currently surveying the different blurring lockers for performance. This one takes about 330ms on my machine, whereas https://github.com/karulont/i3lock-blur (which uses a fragment shader) takes less than 200ms.

andersfylling commented 4 years ago

That's funny. I was curious about the performance. But how did you compile it?

yvbbrjdr commented 4 years ago

I don't think comparing CPU performance with GPU performance makes much sense, since the fragment shader runs on the GPU.

sgraf812 commented 4 years ago

Yeah, I agree. But just wanted to give people a data point, because absolute performance is what matters at the end of the day.

I don't remember how I compiled it. Probably using some Nix files and a lot of tinkering. I came to use vanilla i3lock in the end anyway, paired with xss-lock and its transfer-sleep-lock-i3lock.sh script. I now find that the fact that it properly disables keyboard input is much more important anyway and realised that it was the kind of performance I was interested in after all. Waiting 200ms or 2s for the lock screen to show up is not that important.

andersfylling commented 4 years ago

I just wondered if you compiled it with debug information as well. Cause then there's no real point in comparing performance.

I understand comparing gpu and cpu is weird. But since the point was to compare which had the fastest solution for blur and lock, I think it's still a relevant comparison as it lets you decide which solution would be better for you.

In that case though it would be nice to see a script for reproducibility.

sgraf812 commented 4 years ago

In that case though it would be nice to see a script for reproducibility.

I don't have that "script" anymore (it was just time i3lock-blur vs. time i3lock-fancy-rapid, I think. I just realised I don't even recall the blurring parameters), nor if I compiled in debug mode or not. I'd readily withdraw my bold claim from the OP, but I did it in the first place as a reminder for myself should I ever re-evaluate which locker to use.

So I guess the actual thing I'm missing is a qualitative performance comparison in general, rather than just saying "this is faster than i3lock-fancy".