After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660837 - RFE: offer sane animated background support
RFE: offer sane animated background support
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-03 21:38 UTC by Bill Nottingham
Modified: 2018-07-14 01:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bill Nottingham 2011-10-03 21:38:07 UTC
Someone in Fedora-land noticed a backgrounds package that was 95MB or so in size.

It was this way because it ships 50 frames each in 5 different resolutions to 'animate' a background of the earth and moon rotating around each other.

This is a truly wasteful way to do that, of course. We have neat 2D and 3D drawing toolkits, and GL support, and compositing managers - designers of animated backgrounds should be able to create them in a sane way where they can change color gradients, move and rotate objects, etc. without having to resort to shipping what amounts to a bad version of a FLIC file.
Comment 1 Matthias Clasen 2011-10-03 22:34:45 UTC
whoever decided that '50 frames in 5 different sizes' was a good idea should have looked at the limites of the offered functionality...

adding gstreamer support for backgrounds is certainly not a priority
Comment 2 André Klapper 2011-10-04 06:45:46 UTC
What is the request in this bug report?
Comment 3 Bill Nottingham 2011-10-04 17:47:34 UTC
For someone who wants to create an animated background, give them a better mechanism than just an XML-driven slideshow; whether it's a scene description language that they can script, or using gnome-online-accounts to pull photos from an associated online account, or just giving the developer a window they can render into.
Comment 4 Bastien Nocera 2013-01-27 21:47:35 UTC
Animated backgrounds will soon be handled directly in gnome-shell.

*** This bug has been marked as a duplicate of bug 682427 ***
Comment 5 Jasper St. Pierre (not reading bugmail) 2013-01-27 21:53:51 UTC
I don't think it makes sense to add a full animation scene language or something like that for backgrounds. Putting the rendering code in the shell doesn't really change much.
Comment 6 Ray Strode [halfline] 2013-02-07 21:03:02 UTC
mccann at some point hacked in support for the windows background format. we could look into supporting that, maybe.
Comment 7 Jasper St. Pierre (not reading bugmail) 2013-02-07 21:17:16 UTC
(In reply to comment #6)
> mccann at some point hacked in support for the windows background format. we
> could look into supporting that, maybe.

We can't do that in the compositor. It would have to be in a separate process, like how Nautilus works.
Comment 8 Bastien Nocera 2013-03-28 07:40:45 UTC
gnome-shell is now the sole component responsible for background handling, reassigning.
Comment 9 Giovanni Campagna 2013-03-28 14:01:48 UTC
Yes, but as Jasper said in comment 7, this is likely wontfix. This kind of complex background rendering is better handled in a separate process painting a desktop window.
Comment 10 Ray Strode [halfline] 2013-03-28 14:54:56 UTC
I think having more dynamic backgrounds would be kind of neat.  I don't think very many people are really happy with the current slide show support. Though, this type of thing could really start out (and potentially ultimately stay) as an extension.

One interesting thing is, we watch the file, so a poor mans animation could be implemented as:

$ crontab -e 
5 * * * * curl -O "http://something" > ~/Pictures/background.png

or so.

Anyway, my take is:

1) This isn't a crucial feature
2) I do think there could be a place for subtly animated backgrounds (ala android).
3) We should start by coming up with a design and then worry about the implementation.
Comment 11 Florian Müllner 2018-07-14 01:20:22 UTC
(In reply to Giovanni Campagna from comment #9)
> Yes, but as Jasper said in comment 7, this is likely wontfix. This kind of
> complex background rendering is better handled in a separate process
> painting a desktop window.

Yeah, I agree (even with wayland) ...