Performance improvements, and (fractional) DPI scaling #53
Conversation
ids1024
force-pushed
the
cosmic-bg-speed
branch
from
8dd29cf to
2940dcf
Compare
ids1024
force-pushed
the
cosmic-bg-speed
branch
from
08e6ac6 to
74e9aa6
Compare
|
Performance seems good with |
ids1024
force-pushed
the
cosmic-bg-speed
branch
4 times, most recently
from
01f87b4 to
4a9e921
Compare
|
I think it should be possible to improve the performance of all three scaling modes, with I guess cosmic-bg still needs to properly handling DPI scaling (#51). I guess it should bind the fractional scale protocol... |
ids1024
changed the title
|
I think the fractional scaling implementation I've added is correct. Though there are still a few details to improve here. |
|
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
force-pushed
the
cosmic-bg-speed
branch
from
6e53e5d to
cf424d0
Compare
src/wallpaper.rs
Outdated
| img.width() != layer.width || img.height() != layer.height | ||
| }) { | ||
| let CosmicBgLayer { width, height, .. } = *layer; | ||
| let fractional_scale = layer.fractional_scale.unwrap(); |
There was a problem hiding this comment.
So we require the fractional-scale protocol now?
There was a problem hiding this comment.
I'm assuming cosmic-bg isn't really targeting compositors other than cosmic-comp, so there's no harm in depending on protocols cosmic-comp provides. (Especially if it's a standard protocol other current compositors should support.)
We could definitely not require it, but it makes this a bit more complicated, particularly if we still want to support integer scaling without the protocol.
Anchoring to all edges will do that automatically, and should adjust if the resolution changes.
We don't draw until we get an initial configure, so there's no need to have the size before then. `first_configure` was never set to `true`, so the logic there wasn't right. And I was seeing more draws than needed with multiple monitors, slowing things down. Instead have a `needs_redraw` field that is set when a surface should be drawn, due to a new configure. This is at least better than how this was behaving.
Now requires viewporter and fractional scale Wayland protocols.
`fast_image_resize` provides a range of scaling algorithms, but much better optimized than those in `image::imageops`, including SIMD optimization. This noticeably improves startup time.
ids1024
force-pushed
the
cosmic-bg-speed
branch
from
8421dc4 to
a1f0033
Compare
ids1024
changed the title
|
Apparently it was 69c7b5f that previously removed the use of Not sure if |
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:
tiny_skiafor scaling;image::imageopsseems pretty inefficient in comparison.RUST_LOG=debug cargo run --releaseshows much better wallpaper draw times.It also is drawing 6 times, for just 3 outputs, also adding to run time. It seems
first_configureis never set to anything other thanfalse? Presumably some change should be made there.tiny-skiaonly handles RGBA8. So I guess we may need to fallback toimageopsfor HDR source images, if anyone is using those. I also have only tried updating thezoomscaler, but the others can probably be done more efficiently with tiny-skia as well.