GIF support may be going away on Linux using GDK in the future

[jonahgraham]

Describe the bug

On Linux, the GTK port uses gdk-pixbuf to decode image files. The gdk-pixbuf maintainers consider gif (and a few other formats) "fringe" and are looking to not support them anymore in the future. See this PR in gdk-pixbuf. For now gdk-pixbuf have simply disabled them by default, and we are relying on Distros to make them enabled. In the future they may split gif handling into a new package for distros.

The first version of gdk-pixbuf that changed this default is 2.42.11(versions >= 2.24.11 can still include gif support though)

Please see eclipse-packaging/packages#187 for more background.

To Reproduce

Not 100% sure how to reproduce, but opening gif files on a system with the missing decoder would do it.

Screenshots

See eclipse-packaging/packages#187 (comment) for screenshots and logs.

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

Linux only, but see above description for additional environmental info.

Workaround (or) Additional context

Long term Eclipse may need to resolve gif support if it gets dropped fully. This seems unlikely in the near term. If it does get dropped, there are ~32K gif files in SimRel. It may be simpler to have a fallback Java based gif loader rather than expect all projects to change.

I have created this issue here to ensure that SWT maintainers are aware of the potential problem. We are not sure that the user in eclipse-packaging/packages#187 actually hit this problem or some other issue due to configuration in their Linux install. Their problem was resolved with a distro re-install.

[akurtakov]

I can't even imagine Linux distro without support for gif files aka there might be some temp issues like the one seen one but they will (hopefully!) be resolved before this hits an LTS release. At least that's my hope!

[Phillipus]

A user of our RCP app ran into this on NixOS with bmp files so it can happen. I replaced the files with png files but can't guarantee that some underlying parts of Eclipse use gif. So not just a problem for Eclipse, but also RCP apps.

[laeubi]

SWT already has GIFFileFormat (among others), so for me it seems more an issue of that we need to detect that an image format is not supported and then fall back to the "non native" java counterparts?

[pcdavid]

Maybe related: I've recently updated my system to Fedora 41 (released last week), an by default BMP and XPM image formats are no longer supported. It's not specific to Eclipse but this impacts the icon.xpm application icon and the splash screens of my various Eclipse installs (the splash screens shows as a white square image).

The workaround is to install gdk-pixbuf2-modules-extra (source1, source2).

[mickaelistria]

Thanks for the heads up @pcdavid ! Would you mind opening a separate issue (and even PRs?) to track the recommendation to drop BMP and XPM altogether in Platform?

[laeubi]

SWT also already has WinBMPFileFormat. XPM is a simple text format and there are already implementations for that, for example here

So instead of any dropping for support, I think it is more worth to think about a proper fallback mechanism if there is no native support especially in the light of Initiative 31 (FYI @HeikoKlare @tfroment e.g AWT/Swing already have such (extensible) plain java support, I don't see any benefit in rely on the "native" support here as this is heavily platform dependent and also depends on the actual installed packages as shown here...

[akurtakov]

The gif format support in SWT has its set of problems (https://bugs.eclipse.org/bugs/show_bug.cgi?id=115652 , https://bugs.eclipse.org/bugs/show_bug.cgi?id=560298 , etc.) and it was the reason why using native libs was done . Using third-party dependencies in swt is a can of worms that no one dared to open yet and it would be an adventure of its own when someone decides to go that path.
IMO all of the following could/should happen independently from each other (if/when someone feels like its worth his time):

• implement fallback mechanism to existing pure java image codecs that are part of swt now
• improve pure java codecs in swt to support latest specs of these formats
• replace gif/bmp/xpm files whenever/wherever spotted in the sdk with png files - it's the de-facto standard in the SDK and the fact that other formats are still shipped is a result of neglected code and not on purpose
• work with OS providers to ensure that image codecs are not that dropped

[laeubi]

I understand there are pro and cons for all options, but limited support is better than no support (while I'm not sure if 1 color or animated gifs are really important these days), so I was more thinking about SWT is falling back to the "custom" implementation when the "native" does not (any longer) works, especially for XPM it seems a good opportunity to simply embeds the code (if allowed) into SWT as we most likley would require adjustment for SWT vs AWT anyways... The good thing for all these formats unlikely evolve anymore.

[akurtakov]

There are no cons (other than time spent) in all the options IMO and they are even mutually beneficial.
Now for the XPM case specifically I feel obligated to share the details so we don't end up with theoretical discussions here - embedding in swt would not help as it's used for the splash screen which itself is loaded before swt is started in equinox launcher ( https://github.com/eclipse-equinox/equinox/blob/2815608394cba2ec5529c7a5ec861e7c34113dd2/features/org.eclipse.equinox.executable.feature/library/gtk/eclipseGtk.c#L270 ) . I strongly believe it will be less work to support PNG (most likely a bunch of extension checks in various places) for splashscreen than adding such native image codec into launcher and that can produce proper GdkPixbuf for Gtk to display.
If we want to go down the rabbit hole we can discuss whether splashcreen is needed at all and so on and on but I don't believe this would be suitable here and if anyone wants to start it - please do in separate and dedicated issue.

[laeubi]

At least @pcdavid is/was talking about the icon (of the launcher), I though splahscreen is and always was a (special) BMP format....

[akurtakov]

At least @pcdavid is/was talking about the icon (of the launcher)

citing him "but this impacts the icon.xpm application icon and the splash screens of my various Eclipse installs (the splash screens shows as a white square image)." So I started writing for one thing and went to the other - multitasking not working for me lately. But this means BMP files are not working under Linux for the splash for the reason I wrote previously and fallback will not help for the very same reason again.
The app icon is a chain of problems bigger than the image format alone as it has another very long standing problem (https://bugs.eclipse.org/bugs/show_bug.cgi?id=526678) which everyone on wayland already got used to no app icon due to it thus not noticing the issue.

[mickaelistria]

To tweak the local .desktop file, you can use this PNG icon which I created from the artwork resources on eclipse.org pages.

I quickly tried committing it locally and including it in the .product instead of the .xpm file but this didn't work. I suspect something in the chain mandates some old formats and ignore newer ones.

[laeubi]

This is specified here:

https://www.eclipse.org/articles/Article-Branding/branding-your-application.html#launcher_branding

On Linux we also need to copy the icon.xpm (we created above) to the eclipse/ root replacing the one already found there.

so this is quite "baked in" I have no clue why xpm (maybe because it is scalable?) was chosen in the past, but actually SVG would be more appropriate than PNG here, at least on Debian all icons seem to be SVG for applications now.