-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
That's funny. I was curious about the performance. But how did you compile it? |
I don't think comparing CPU performance with GPU performance makes much sense, since the fragment shader runs on the GPU. |
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 |
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. |
I don't have that "script" anymore (it was just 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". |
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.
The text was updated successfully, but these errors were encountered: