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 623174 - Nautilus background fade has performance issues
Nautilus background fade has performance issues
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: [obsolete] Backgrounds Emblems and Themes
2.31.x
Other Solaris
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-29 22:30 UTC by Brian Cameron
Modified: 2010-10-18 12:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch fixing issue (2.43 KB, patch)
2010-06-29 22:30 UTC, Brian Cameron
needs-work Details | Review
updated patch (4.95 KB, patch)
2010-07-07 05:33 UTC, Brian Cameron
none Details | Review

Description Brian Cameron 2010-06-29 22:30:49 UTC
Created attachment 164930 [details] [review]
patch fixing issue

When you log into the desktop, nautilus will do a crossfade of the desktop background between the GDM background image and the user's background.  In the
normal situation (e.g. a single-user desktop or laptop) this works great.

However, when you have configured GDM to be an XDMCP server and the client machines are logging in over long distances, the network latency can be high.  Watching the crossfade paint is painful and can take dozens of seconds.  Even on a high-speed LAN network I see the fade taking a couple of seconds.

It would be nice if people who want to configure an XDMCP server could disable this cross-fading feature.  In such environments, it is much nicer and faster to avoid the crossfade and simply switch the background image.

I have attached a patch which adds a new boolean GConf key named:

  apps/nautilus/preferences/background_fade

Which is set to true by default so the normal behavior continues to be the crossfade.  However, this configuration option provides sysadmins running environments like an XDMCP server to change the setting to false to avoid the
problematic behavior I describe above.

If the patch needs any additional work, please let me know and I would be happy to rework if needed.
Comment 1 Cosimo Cecchi 2010-07-04 13:33:02 UTC
Review of attachment 164930 [details] [review]:

Hi Brian, thanks for the patch.
I understand the need for that kind of option, and it's fine for me to add a configuration entry for it.
I commented the patch below.

::: nautilus-2.30.1/libnautilus-private/apps_nautilus_preferences.schemas.in-orig
@@ +187,3 @@
 	
+        background->details->do_fade = gconf_client_get_bool (client,
+			 NAUTILUS_BACKGROUND_FADE_KEY, NULL);

We don't want to use Nautilus GConf keys from eel; although eel is not a standalone library anymore, the code in it is usually self-contained and not specific to nautilus.

Can't you have a property on EelBackground (use-fade or somesuch), have the GConf option in nautilus and set the property from there?
Comment 2 Brian Cameron 2010-07-07 05:33:20 UTC
Created attachment 165396 [details] [review]
updated patch


Thanks for the review.  Here is an updated patch that adds a function eel_background_set_fade and moves the reading of the GConf key to the libnautilus-private/nautilus-directory-background.c file.  In my testing, this patch also works fine.

You suggest making this a property.  Is it okay to be a function like I used in the patch?  If not, could you help me to understand why.

I would think making it a property would be useful to make nautilus handle if the key value changes while nautilus is running.  If so, I do not think this is needed or would add much value.  This GConf key really only affects when the background is drawn at the beginning of the user session, so if the user changes the value of the key during their session, then I would think it would be fine for nautilus to just pick up the change when it is next restarted (when the user starts their next user session).  In most environments where this key would be used, it would likely be set as a mandatory system setting to avoid performance issues, so it's probably not a key that users would change anyway.
Comment 3 Brian Cameron 2010-09-16 06:28:48 UTC
*ping*

I think this is a fairly straightforward patch and it adds some good value.  gnome-settings-daemon also has similar code, and I'd like to fix that also, but since g-s-d uses the nautilus GConf keys, it makes sense to first get this fix upstream before making the similar change there.

Can this go upstream, or does the patch need more work?

Thanks.
Comment 4 Cosimo Cecchi 2010-10-13 15:58:46 UTC
Brian, sorry for the delay, but I planned to refactor the EelBackground code during this development cycle (and migrate nautilus to GSettings too), so I waited for that to happen before going back to this patch.

I now pushed to master another patch, similar to yours, which uses the new NautilusDesktopBackground code and GSettings instead of GConf for the option (which now uses the /apps/nautilus/desktop/background-fade key).

Closing as FIXED.
Comment 5 Brian Cameron 2010-10-13 17:51:09 UTC
For reference, here is the change from GIT:

http://git.gnome.org/browse/nautilus/commit/?id=01f39f471005e788281c18da30563c0184434fff

Note that the g-s-d "background" plugin also has similar code to manage the background which is used when nautilus is not being used to manage the background.  The g-s-d background plugin also has a similar fading feature which you cannot configure to disable.  Since the g-s-d plugin refers to the nautilus configuration to decide how to manage drawing the background, it probably makes sense to add this new configuration option there as well.

Further, I notice that the g-s-d 2.91.0 background plugin is still using GConf, so it probably needs to be updated to use the new GSettings configuration now used in Nautilus.

I filed bug 632081 to request that g-s-d also refer to this configuration option to disable the fading effect when the user wishes, and highlighted that there is probably the need to migrate g-s-d to use the new nautilus GSettings configuration instead of using GConf.
Comment 6 Cosimo Cecchi 2010-10-13 18:03:48 UTC
(In reply to comment #5)

> Further, I notice that the g-s-d 2.91.0 background plugin is still using GConf,
> so it probably needs to be updated to use the new GSettings configuration now
> used in Nautilus.

Note that the desktop background settings themselves are not in GSettings yet (neither in nautilus, nor in gnome-setings-daemon, nor in gnome-desktop's GnomeBG, which is the component that actually reads/writes the background settings), just the 'background-fade' option.
Comment 7 Brian Cameron 2010-10-13 18:11:57 UTC
Are there plans to migrate the background settings to GSettings?  It doesn't seem to make sense to have a mix like this.

Note that bug #632081 was marked as a duplicate of bug 583757.
Comment 8 Cosimo Cecchi 2010-10-13 18:16:53 UTC
(In reply to comment #7)
> Are there plans to migrate the background settings to GSettings?  It doesn't
> seem to make sense to have a mix like this.

Yes, see bug 626018 and its dependencies (gnome-desktop's GnomeBG needs to be ported first).
Comment 9 Tomas Bzatek 2010-10-18 12:29:01 UTC
Brian, the g-s-d background plugin shares most of the code with Nautilus. With gnome3 changes going on, Nautilus may not be the component handling desktop background. It is a good idea to make this option global, i.e. move to gsettings-desktop-schemas like I'm trying for another option in bug 632225. But of course, gnome-bg should be ported to GSettings which I am trying to finish now.