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 575964 - GnomeBG should give up the fade effect if it's too slow
GnomeBG should give up the fade effect if it's too slow
Status: RESOLVED OBSOLETE
Product: gnome-desktop
Classification: Core
Component: Background
2.26.x
Other All
: Normal enhancement
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-19 14:02 UTC by scott
Modified: 2018-09-21 16:28 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Attachments
Patch to removal initial fade-in only (417 bytes, patch)
2009-03-19 14:03 UTC, scott 		rejected Details | Review

Description scott 2009-03-19 14:02:42 UTC 
The recently added cross-fade support also fades in the initial background from nothing.  This is happening at an extremely busy time for the desktop (login), when the window manager itself may not even be up to speed.

In the cases of compositing window managers, it pretty much kills the login performance.

Additionally while cute, with KMS we can do much better "fade in the entire desktop" kinds of things
Comment 1 scott 2009-03-19 14:03:22 UTC 
Created attachment 130970 [details] [review]
Patch to removal initial fade-in only
Comment 2 Cosimo Cecchi 2009-03-19 14:56:46 UTC 
-> gnome-desktop

From an IRC discussion, it turns out this is mainly a driver issue, and the feature itself is a nice thing to have.
GnomeBG should instead have some kind of heuristic and gove up the fade if we can't draw the effect fast enough to make it smooth and fast.
Comment 3 scott 2009-03-19 15:18:39 UTC 
I'm not sure it is a driver issue,
the fade uses up a fair amount of CPU time and I/O traffic - and if you're using compositing, you're sending a very large number of entire-window changes right at the start
Comment 4 Alexander Larsson 2009-03-19 16:13:20 UTC 
In the compostied case, maybe we could fade in using a window-wide alpha which we move from 0 to 1.0 instead. That way we'd move the compositing to the cm and not cause lots of damage, avoiding the window copies caused by that.
Comment 5 Vincent Untz 2009-06-16 23:18:02 UTC 
Reject the patch, see comments from Cosimo and Alex.
Comment 6 GNOME Infrastructure Team 2018-09-21 16:28:26 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/25.