Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This is slower than i3lock-blur #11

Open
sgraf812 opened this issue Mar 23, 2020 · 5 comments
Open

This is slower than i3lock-blur #11

sgraf812 opened this issue Mar 23, 2020 · 5 comments

Comments

@sgraf812
Copy link

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
Copy link

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

@yvbbrjdr
Copy link
Owner

yvbbrjdr commented Jun 7, 2020

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

@sgraf812
Copy link
Author

sgraf812 commented Jun 7, 2020

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
Copy link

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
Copy link
Author

sgraf812 commented Jun 7, 2020

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants