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

GPU acceleration #175

Open
jaredmontoya opened this issue Aug 7, 2024 · 9 comments
Open

GPU acceleration #175

jaredmontoya opened this issue Aug 7, 2024 · 9 comments
Assignees
Labels

Comments

@jaredmontoya
Copy link

It's almost necessary to have GPU acceleration in the current day and age. Without it viewing big images will always be painful, it's just a matter of how big they can get before you feel it.
Thank you in advance!

@artemsen artemsen self-assigned this Aug 7, 2024
@artemsen
Copy link
Owner

artemsen commented Aug 7, 2024

The only problem is that I couldn't find a way to draw GL texture (image) on a transparent window.
Not now, but maybe I'll return to this issue a little later =)

@qaako
Copy link

qaako commented Aug 22, 2024

I don't know anything about anything, but I have heard on IRC before, concerning the topic of why feh only uses 15MB per image and there are no lightweight image viewers that support native wayland, that loading a mesa context automatically creates 100MB RSS usage. This makes a lot of sense of why imv is such a memory hog.

If you do add GPU acceleration, I hope it doesn't increase resource usage, because I'd rather render an image 10x slower than even increase RAM usage by 25%. I like to keep 20+ images open and the RAM usage multiplies quickly with most image viewers.

It would be a nice feature if it doesn't have caveats, but this image viewer being the most lightweight is my favorite thing about it. If someone is after cycling through a gallery at maximum rendering speed, there are plenty of heavier image viewers to do the job. Personally, I think Eye of Gnome or LXIMage-QT would accel for that purpose (using a single main window and cycling through gallery) But there are loads of alternatives for this use case. Swayimg is awesome for keeping tons of windows open with a low resource footprint... And it's the only app of its kind on Wayland. I know I'm just one user here, but I would really hate to see this change.

@jaredmontoya
Copy link
Author

Well, It's not about scrolling through a gallery at maximum speed, it's about viewing 8k images and not having fps drop to 5 while it's moving.

@diniamo
Copy link
Contributor

diniamo commented Aug 22, 2024

I think there is no real point being made here either, if GPU acceleration were to be implemented, it would be behind a build flag, and a toggle.

@artemsen
Copy link
Owner

To be honest, I don't see any pressing need for this feature.
GPU support in this case will save RAM by using video memory and will provide the ability to smoothly drag with the mouse.
If you don't have a discrete GPU with dedicated VRAM, then the first advantage is questionable.
The smooth drag issue has been partially resolved in version 2.5, I would say "completely resolved" if you turn off antialiasing.

I just tried opening a 30720 x 17280 pixel image, and the current version of swayimg handles it just fine. In fact, the image size only matters when loading, but the rendering speed depends entirely on the window size.

@diniamo
Copy link
Contributor

diniamo commented Aug 23, 2024

Well yes, there is the issue, I would like to have antialiasing enabled. This is only a slight annoyance though, whatever was done in 2.5 works really well, compared to before.

artemsen added a commit that referenced this issue Sep 14, 2024
Reduces the time it takes to render an image, especially when
antialiasing is enabled.

Relates to #175.

Signed-off-by: Artem Senichev <[email protected]>
@artemsen
Copy link
Owner

@diniamo, I added support for multi-threaded rendering. On an eight-core processor the rendering time for a 2560x1440 window was reduced from 0.4775 sec to 0.1250 sec (with antialiasing enabled).
Hopefully this workaround will help until we have GPU support.

@diniamo
Copy link
Contributor

diniamo commented Sep 15, 2024

Nice, seems to make antialiasing usable. Thanks

@bvergnaud
Copy link

If someone is after cycling through a gallery at maximum rendering speed, there are plenty of heavier image viewers to do the job.

Just to add to the discussion, the rendering speed is not only important for cycling through images fast (although it's nice to have) but also for animated formats such as GIF or AVIF.

A 20 fps GIF is neither uncommon nor particularly high quality, especially because GIFs are often low resolution. But until the multi-threaded rendering commit, a lot of them (in my library at least) would not render at 20 fps with antialiasing turned on.

I added support for multi-threaded rendering. On an eight-core processor the rendering time for a 2560x1440 window was reduced from 0.4775 sec to 0.1250 sec (with antialiasing enabled). Hopefully this workaround will help until we have GPU support.

Just found this commit and it's great, much faster and smoother rendering already. Thanks. 🙏🏻

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

No branches or pull requests

5 participants