Issues with timed backgrounds in F41

At 5:04pm today, this is how my F41 desktop background suddenly appeared:

It’s now 5:53pm, and I see this:

I’m using the F41 timed background, and the “transition” stages appear to just not be working — instead of blending the “from” and “to” images, the transition stages appear to blend from black to the “to” image.

I documented this over at GNOME Shell animated background fade logic still seemingly gets confused by the passage of time (#237) · Issues · GNOME / GNOME Utility Library · GitLab but I also wanted to ask here: Am I the only one seeing this? I’d think there would be more widespread reports, if it’s a common issue.

So, perhaps it’s something with my combination of display server (Wayland), graphics card (dirt-cheap Nvidia GT710), and drivers (nouveau)?

It’s definitely not limited to the F41 background — I observed the same issues with the Fedora Infinity background as well, just at different times of day because the timing of the <transition> elements in its XML file is different.

This is likely an old issue when a wallpaper runs on RGBA format in PNG, that the developers are aware of. There was even an easy fix for using the optipng command in the spec files and a scratch build that I tested and gave feedback on. Unfortunately, the package was never built with the fix, so I fixed it locally on my systems.

At least on my end (Fedora Silverblue 41 custom container image), when I convert the images in the /usr/share/backgrounds/f41/default directory from PNG to WebP and edit the /usr/share/backgrounds/f41/default/f41.xml file to reference them, the overlay transitions work as expected. As an added benefit, the file sizes of WebP images are roughly halved with no visual quality loss as far as I can see.

1 Like

HUH! I think you’re on to something there, as in my initial testing I didn’t seem to see this happening with the F40 background, and one of the ONLY differences between F40 and F41 (the timings in the XML are all the same) is the image format:

$ file /usr/share/backgrounds/f40/default/*.png |fmt -w 70 -s
/usr/share/backgrounds/f40/default/f40-01-day.png:   PNG image data,
4032 x 3024, 8-bit/color RGB, non-interlaced
/usr/share/backgrounds/f40/default/f40-01-night.png: PNG image data,
4032 x 3024, 8-bit/color RGB, non-interlaced

$ file /usr/share/backgrounds/f41/default/*.png |fmt -w 70 -s
/usr/share/backgrounds/f41/default/f41-01-day.png:   PNG image data,
4032 x 3024, 8-bit/color RGBA, non-interlaced
/usr/share/backgrounds/f41/default/f41-01-night.png: PNG image data,
4032 x 3024, 8-bit/color RGBA, non-interlaced

The Infinity backgrounds (which also showed the blanking issue) are ALSO RGBA format.

Fixing the images with ImageMagick (while keeping the PNG format) is as easy as:

magick <in_filename>.png -alpha off <out_filename>.png
# Or, in-place...
magick mogrify -alpha off <filename>.png

The fix in spec files was basically to convert RGBA in RGB for PNG format using optipng. It’s just that I personally prefer the WebP format.

Ah, here’s a report in the upstream repo of the same issue (back in the F38 days): Time-based transition is broken · Issue #51 · fedoradesign/backgrounds · GitHub The fix was, as you say, to remove the alpha channel from the files.

So this is definitely kind of a known thing, it’s just that the channel processing was never integrated into the packaging — which it should be, because people are going to keep forgetting that the images need to be RGB and not RGBA.

My only issue with optipng is that it does stuff, and doesn’t give you a lot of control over WHAT stuff it does. Like, optipng -o0 won’t remove an alpha channel from the input. optipng -o1 will, but it’ll also potentially do other stuff. With ImageMagick, it’s possible to say “remove the alpha channel AND NOTHING ELSE” — a level of control that optipng doesn’t appear to provide.

Issue opened upstream: F41 timed transitions broken (again) due to alpha channel (again) · Issue #67 · fedoradesign/backgrounds · GitHub

2 Likes