GPU acceleration

[jaredmontoya]

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]

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]

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]

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]

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]

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]

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]

@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]

Nice, seems to make antialiasing usable. Thanks

[bvergnaud]

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. 🙏🏻