#3376 Change: Switch to JXL format for Default Wallpaper
Closed: Accepted 18 days ago by decathorpe. Opened a month ago by amoloney.

The default Fedora wallpaper will switch from PNG to JXL format.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.


+1

(Fwiw, due to some confusion, this has been mostly implemented already)

@frankjunior This ticket is for FESCo members only to vote.

Hmm, I like the change in general, but the reported performance regressions seems quite problematic. Have they been resolved? If they haven't, and we don't have a simple fix in sight, I think we should push this out to F43.

Hasn't this already been reverted in GNOME 48 upstream - citing performance problems, i.e. login taking 10seconds+? I don't think that's a good sign.

Hasn't this already been reverted in GNOME 48 upstream - citing performance problems, i.e. login taking 10seconds+? I don't think that's a good sign.

That seems valid for medium aged hardware according to the very ticket. Upstream libjxl asked details to reproduce the issue which has yet to answer from the reporter. We still have final release to address the issue should the problem occurred on several hardware.

I'll put a procedural -1 to prevent automatic approval.

This got stalled. Did the questions about performance regressions get resolved? What is the decision in GNOME upstream?

I'll put a procedural -1 to prevent automatic approval.

This got stalled. Did the questions about performance regressions get resolved? What is the decision in GNOME upstream?

JXL is no longer considered the top culprit.

libjxl 0.11.x sufficiently resolved the issues, and we have that in Fedora 42 already.

I suppose that makes me a +1 then.

Hello, I'm a little concerned about this change, not because of the load time, but because wallpaper tools based on python, external to Gnome, like nitrogen, azote, wallpapoz as well as other doesn't have the support yet, since python-pillow doesn't have the support yet.

There are plugins that provide some support, but the official code of python-pillow is not done

I know you officially doesn't care about spins, but it's worth noticing that on testing (F41 fully updated), I wasn't able to see the wallpapers on JXL format on:

  • Budgie (Budgie Control Center is provided as tool)
  • i3wm (Azote is provided as tool)
  • LXDE (I'm not sure what tool it is, you can select the jxl, but it's not loaded as wallpaper)
  • LXQt (I'm not sure what tool it is, but the tool is pre-configured to some file extensions, jxl is not on the list)
  • Cinnamon (Part of the cinnamon-control-center)
  • SOAS (The tool is not configurable, but after updating the background package, it didn't show the JXL file)
  • Mate (The mate system preference tool. You can "Add" the file, but it's not shown to be selected)
  • XFCE (The XFCE Desktop tool, doesn't show JXL files in the folder selected)
  • KDE (The Desktop Folder Settings tool. You can select the file, because it's detected as image, but it did'n load. Even Gwenview didn't load the file)

I wasn't able to find the graphic tool to change it in the following spins:

  • MiracleWM (It doesn't have a tool, but I tried with Thunar File Manager and it didn't detect the JXL file as image)
  • Sway (It doesn't have a tool, but I tried with Thunar File Manager and it didn't detect the JXL file as image)

I will test this on F42 beta, but iso files are downloading now.

Indeed, for f42 beta it works for the spins based on GTK and Qt. For the Window Manager, it get set at installation (checking why in the i3 it doesn't work on the live session), but still can't be changed:

  • Sway and Miracle doesn't have an application for it, but Thunar File Manager doesn't show the option to "Set as wallpaper" that is shown with jpg and png files; for sway, imv can read the files (which makes sense because it's written in C), but no app can be use to set the wallpaper.
  • i3wm uses azote and as stated before, python apps doesn't have support yet.

In WM cases feh could be used to change the wallpaper, but it's not ideal.

Sway and Miracle both use swaybg, and swaybg is supposed to use gdk-pixbuf.

Thunar isn't supposed to show a set wallpaper option on non-Xfce/GNOME environments. But even if it was, Thunar has a hardcoded list of mimetypes to offer it, regardless of what the desktop supports: https://gitlab.xfce.org/xfce/thunar/-/blob/master/plugins/thunar-wallpaper/twp-provider.c#L151-155

That list needs updating to add WebP, AVIF, and JPEG-XL.

swaybg it's equivalent to feh in the way that it's command-line, so it's still not ideal.

Yes, but there is no "interface" for graphical applications to set the wallpaper in MiracleWM and Sway since swaybg does not offer one. It's just invoked as a CLI tool and sets up a background layer-shell object for the wallpaper.

Yes, but there is no "interface" for graphical applications to set the wallpaper in MiracleWM and Sway since swaybg does not offer one. It's just invoked as a CLI tool and sets up a background layer-shell object for the wallpaper.

That's my point. In the i3 spin we use Azote (as greaphical interface), on CLI we use feh. I think it's the normal workflow for changing the wallpaper either use the file manager or an specific tool that do the job.

We could use Azote on MiracleWM as we use the other nwg-shell components there already. Azote is a swaybg wrapper anyway. For Pillow, we should probably ship https://github.com/Isotr0py/pillow-jpegxl-plugin or https://github.com/olokelo/jxlpy and wire it up accordingly.

With Xfce, you can set the default to a jxl file, but you cannot choose those files manually (I hope to get time to file this upstream soon).

This change seems like a lot of churn for not much gain to me. :(

I guess I won't stand in the way as others are all ok with it.

If Gnome and KDE works, it's going to happen, nothing else matters

With Xfce, you can set the default to a jxl file, but you cannot choose those files manually (I hope to get time to file this upstream soon).

It's an easy enough fix to make at least.

This change seems like a lot of churn for not much gain to me. :(

The main gain is the reduction of disk space for high-resolution imagery. PNG files were getting extremely big.

I filed https://gitlab.xfce.org/xfce/thunar/-/merge_requests/620 / https://src.fedoraproject.org/rpms/Thunar/pull-request/2 with the change Neal suggested.

With this, and the JXL loaders installed for GTK and Qt, are we fine on all desktop envs?

We should be. I had already went around and asked for GNOME, KDE Plasma, and COSMIC last year when this topic first came up. Pretty much everyone should be set. Azote still needs Pillow to support JXL for thumbnail generation somehow, but it should still let you select a JXL wallpaper.

I think we can get one of the jxl plugins for pillow packaged and patch in its use into Azote to resolve that.

Enumerating my research from last year:

  • gnome, cinnamon, xfce, mate, and lxde use gdk-pixbuf (so jxl-pixbuf-loader works)
  • kde and lxqt use qimage (so kimageformats works)
  • swaybg and feh use gdk-pixbuf (so jxl-pixbuf-loader works)
  • cosmic-bg uses image-rs and jxl-oxide

For Azote, I've got a package review up for pillow-jpegxl-plugin: https://bugzilla.redhat.com/show_bug.cgi?id=2354261

Well, no, Xfce is not "fine" here yet. ;)

With the Thunar patch you can set background there to a jxl, but the xfdesktop background chooser/setting still doesn't allow you to do so.

I'm not fully sure why. It seems like it looks for:

            has_image_files = content_type != NULL && g_str_has_prefix(content_type, "image/");

which should match.

+1

It works on sway.
It seems the majority, if not all, DEs/WMs can support this. I would mark it as something to definitely test on every spin before release, just to be sure that we are installing all needed packages

This is finally APPROVED (+6, 0, 0)

Metadata Update from @ngompa:
- Issue tagged with: pending announcement

19 days ago

Metadata Update from @decathorpe:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

18 days ago

Log in to comment on this ticket.

Metadata