I'm using the "Scaled, Keep Proportions" positioning with an image that doesn't match the aspect ratio of my screen - so I should get vertical bars of the background color on each side. When switching from the default "Next by KDE Visual Design Group" to a photograph of the wrong aspect ratio, the old background stays around, filling the area where the "black bars" should be. Reproducible: Always Steps to Reproduce: 1. Set "Wallpaper Type: Image" and "Positioning: Scaled, Keep Proportions." 2. Pick a wallpaper that matches the aspect ratio of your screen. Hit Apply. 3. Pick a wallpaper that is the wrong aspect ratio of your screen (which would produce black bars). Hit Apply. Actual Results: The old image is still visible, where the black bars (technically background color bars) should be. Expected Results: The rest of the screen should have been repainted with the background color. Occasionally it works. Opening the "Background Color" settings and closing it makes it realize it needs to repaint these areas.
Created attachment 91672 [details] Screenshot of the problem - two images at once
Took some time but I managed to reproduce, confirmed.
there are actually two Image elements which the old one will fade out in order to do the transition animation. so perhaps in some conditions the fade doesn't happen?
doesn't seem to happen here. any particular steps to reproduce?
Looks like a repaint issue to me. I added debug output and the opacity of the other image is properly set to zero and when I hover eg the toolbox the area usually blacks properly.
*** Bug 346785 has been marked as a duplicate of this bug. ***
Hi all. I was able to get this working on my system by moving the second opacity change from a ScriptAction into another OpacityAnimator in plasma-workspace/wallpapers/image/imagepackage/contents/ui/main.qml . I'll attach a patch below.
Created attachment 93141 [details] Patch to move wallpaper opacity change into an animator
Thanks for looking into this. In general we tend to use git.reviewboard.kde.org for patches. Though we'll keep working here for this one. It's interesting that you're saying this patch fixes it, it basically does exactly the same as the script animation should be doing, setting the opacity to 0 just earlier. If your thing fixes it , it implies that final script isn't being run at all. If that's the case, I'd rather fix that, than hide the visual symptom as otherwise we end up keeping the other image in memory which is a bit wasteful. could you test if setting alwaysRunToEnd: true on the topmost SequentialAnimation also fixes it?
*** Bug 349115 has been marked as a duplicate of this bug. ***
I'm afraid I'm new to the KDE contribution process. If you'd like to move this over to the review board, I'm happy to set up an account over there too. alwaysRunToEnd: true does not fix the issue. The symptoms are the same as leaving alwaysRunToEnd off entirely. I agree that my patch is doing the same opacity change operations, just in a different order. I do think, based on Kai's Comment 5 above, that the script is run, setting the opacity of the image to 0, but it doesn't redraw the screen afterword. I'm not sure why not though, nor how to force a redraw in this case apart from switching to the OpacityAnimator.
https://git.reviewboard.kde.org/r/124093/
Git commit 6326f09e9b6111a6048f2fc8191f04e8486aaa00 by David Edmundson, on behalf of William Lieurance. Committed on 07/07/2015 at 16:26. Pushed by davidedmundson into branch 'master'. Prevent two wallpaper images showing overlayed when "Scaled, Keep Proportions" is chosen Moving the opacity change from a ScriptAction to a parallel OpacityAnimator. That seems to cause a repaint in whatever weird environment happens to be the root of this bug. REVIEW: 124093 M +14 -6 wallpapers/image/imagepackage/contents/ui/main.qml http://commits.kde.org/plasma-workspace/6326f09e9b6111a6048f2fc8191f04e8486aaa00