Performance improvements, and (fractional) DPI scaling

pop-os / cosmic-bg

Mozilla Public License 2.0

19 stars 22 forks source link

Performance improvements, and (fractional) DPI scaling #53

Closed ids1024 closed 3 months ago

ids1024 commented 3 months ago

I've noticed cosmic-bg is somewhat slow to start, particularly with a couple monitors.

I see it's noticeably better changing a couple things:

Cache the image, instead of opening the file when each monitor is draw. Given I have the same image shown on all monitors.
Use tiny_skia for scaling; image::imageops seems pretty inefficient in comparison.

RUST_LOG=debug cargo run --release shows much better wallpaper draw times.

It also is drawing 6 times, for just 3 outputs, also adding to run time. It seems first_configure is never set to anything other than false? Presumably some change should be made there.

tiny-skia only handles RGBA8. So I guess we may need to fallback to imageops for HDR source images, if anyone is using those. I also have only tried updating the zoom scaler, but the others can probably be done more efficiently with tiny-skia as well.

ids1024 commented 3 months ago

Performance seems good with fast_image_resize. So if the unnecessary additional draws can also be fixed, I'm be happy with the performance of cosmic-bg.

ids1024 commented 3 months ago

I think it should be possible to improve the performance of all three scaling modes, with fast_image_resize. Though some testing is needed to make sure behavior is right. The API is a bit different, though not that complicated.

I guess cosmic-bg still needs to properly handling DPI scaling (https://github.com/pop-os/cosmic-bg/issues/51). I guess it should bind the fractional scale protocol...

ids1024 commented 3 months ago

I think the fractional scaling implementation I've added is correct. Though there are still a few details to improve here.

ids1024 commented 3 months ago

Oh, and I guess I should note that I'm testing with a 6000x4000 (24 megapixel) image from my DSLR. So if I wanted it to be faster I could probably scale that down a bit before cosmic-bg accesses the file. But if performance is good with that, it should handle most reasonable desktop background images. (And I guess scaling multiple times would results in somewhat worse visual quality, in principle.)

ids1024 commented 3 months ago

Apparently it was 69c7b5fdaea935fff6d5564cc7bce797dd1d1408 that previously removed the use of fast_image_resize.

Not sure if fast_image_resize supports 10-bit color (is that why it was removed there?), but this PR still uses the resizing in image as a fallback if fast_image_resize errors due to not supporting a format.