Details
- Reviewers
mart - Group Reviewers
VDG Breeze - Maniphest Tasks
- T10269: Improve wallpapers
Same as in D18005.
Diff Detail
- Repository
- R31 Breeze
- Branch
- keep-only-largest-size (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 6691 Build 6709: arc lint + arc unit
I've reproduced what the issue was before. Tests done with a 1280x1024 monitor.
- Tested on a Kubuntu 16.04 (with backports = 5.8 LTS) install with Plasma
Using the optimized 1280x1024 wallpaper:
Using the scaled & cropped method with the 3840x2160 wallpaper:
As we can see the end result is not good - the wallpaper is blurry.
- Tested on the latest Manjaro KDE stable snapshot
Using the scaled & cropped method with the 3840x2160 wallpaper:
The problem with blurriness is gone. We do, however, see that manual and automatic cropping don't have the same result.
Based on this, I think it should ultimately be up to @kvermette to decide if the automatic scaling and cropping will do injustice to his wallpapers. If so, it does also represent a minus point for Plasma's default presentation.
And from my understanding this removes the file the SDDM theme needs so I created D18007 as a dependent revision.
has runtime memory been taken into account? (better with massif than with the unreliable top/ksysguard)
runtime memory usage should be taken into account as well, loading a big image just to use a little, is still very expensive never the less
According to @davidedmundson, runtime memory is unchanged because we internally store a version that's resized and cropped according to the actual screen dimensions and pixel density.
I said it's roughly unchanged, we resize to the uncropped version of the image.
As per IRC discussion yesterday. We can do it in the extra wallpapers, and see how that goes, lets not change "Next" this release.
Per discussion in D18005, we're not gonna do this for 5.15. Instead we'll try to get a local wallpaper cache, and then we can do it.
-1
This will also reduce load time considerably (I did the profiling before, using the same resolution is a big win).
Also you'll get to save quite some IO.
If this is a problem, I'd suggest looking into doing these wallpapers in svg or even QML.
I just saw what this revision depends on. So it could make sense. I'll leave it at -0 because caches are bad.
The whole point was to save some space on the user's machine. However trading space savings for load time maybe isn't the best trade-off? 18 MB isn't really all that much of a savings.
Should we shelve this idea?
I would go with yes. We also want the default wallpaper to be artistically perfectly cropped in addition to being efficient in all the non-artistic metrics. I think it's beneficial to make the trade off for the addon wallpapers, but this one should just be perfect.