Re: Login time

["Martin Meyer" <elreydetodo gmail com>]

This may seem like a stupid question to anyone who understands things
better than me but I want to ask it anyway. Here it goes...

Why is nautilus responsible for rendering the desktop at all? Why
don't we have some light-weight daemon for this? Maybe there could be
a shared library with Nautilus, but from what I understand Nautilus
pulls in a lot of libraries at startup making it somewhat slow.
Wouldn't it be better to separate the desktop into another process and
lose some extra dependencies? How complex is the code that allows
Nautilus to handle the desktop, and how dependent is it on the rest of
the Nautilus code? Is it feasible to separate the Desktop stuff into a
new daemon which starts faster?

Also, it's fairly annoying when my file browser freezes and killing it
erases everything on my desktop. If we used a separate daemon for the
desktop this would be fixed as an added bonus.

- Martin

On 4/4/07, Dan Winship <danw gnome org> wrote:
> Xan Lopez wrote:
> > I vaguely remember
> > someone mentioning nautilus and the panel are handled in a special way
> > by gnome-session, is this still so?
>
> Yes, this is still true, and metacity as well. The theory is that the
> window manager has to start early, because if any other application
> created a window before the window manager was up and running, the
> window would appear at 0,0 instead of being positioned nicely, and then
> after metacity started, it would have to move the window down to make
> room for the titlebar, and it would look really ugly and lame. Likewise,
> if nautilus were to start before the panel, it might draw desktop icons
> underneath where the panel is eventually going to be, and then after the
> panel started nautilus would have to clear everything and position them
> all again. So you really need metacity and the panel to start before
> everything else. (I'm not totally sure why we also start nautilus before
> everything else. Because we want the desktop background image to be
> drawn early I guess? Or maybe the answer is "because gmc used to do
> something very important which nautilus doesn't do any more, but no one
> realized they should remove the special startup priority when the
> feature went away".)
>
> Anyway, the net result is that GNOME startup goes: launch metacity, wait
> for metacity to register, launch the panel, wait for the panel to
> register, launch nautilus, wait for nautilus to register, launch
> everything else all at once. In theory.
>
> Here's how it works in practice:
>
>     1) Your distro may start a bunch of things before gnome-session even
>        starts. In openSUSE, the list includes ssh-agent, gpg-agent,
>        dbus-daemon --session, various xmodmap and xrdb stuff, and more.
>
>     2) gnome-session launches numerous things separately/specially
>        before the "normal" startup process even begins, including
>        gconf-sanity-check (which has to wait for gconfd to start);
>        at-spi-registryd (if a11y is enabled); gnome-keyring-manager;
>        dbus-daemon --session (if it wasn't already started by a distro
>        script); gnome-settings-daemon; esd (if the login sound is
>        enabled); and vino-server (if enabled). *Each of these is
>        started synchronously, with gnome-session waiting to make sure it
>        is ready before starting the next thing.* (Ugh.)
>
>     3) Then we do the "normal" startup (metacity, panel, nautilus,
>        and all other autostarted/session-saved apps). (The splash screen
>        appears immediately before this step, and disappears immediately
>        after the last application is *launched* [not after the last
>        application *registers*, because gnome-session  has no way of
>        knowing whether an autostarted app supports SM or not, so it
>        can't really wait for it to register]).
>
>     4) Meanwhile, the panel is starting all the applets,
>        gnome-settings-daemon starts gnome-screensaver,
>        gnome-volume-manager, and probably some other things, etc.
>
>
> So, things to look at for optimizing this:
>
>     1) The early special cases in gnome-session are a mess and need to
>        be sorted out. gnome-settings-daemon really does need to be run
>        very early (before anything gets drawn on the screen, since gsd
>        needs to set the XSETTINGS properties for theme, font size, etc),
>        but vino-server certainly doesn't.
>
>        WTF is gconf-sanity-check? Do we *really* need to run it (and
>        wait for its exit status)?
>
>        Some of the things are started early so they can set environment
>        variables for other processes to look at (eg,
>        GNOME_KEYRING_SOCKET). If they were fixed to use D-Bus instead,
>        we could move them to be started later. (Preferably on-demand.)
>
>     2) The "normal" special cases should also be looked at. Metacity and
>        the panel need to be started early for the reasons described, but
>        is there really a good reason to special case nautilus?
>
>     3) For any program that we decide really must be up and running
>        before other applications run, we need to make sure that it does
>        exactly the right amount of initialization before it registers
>        with the session manager. "Exactly the right amount" means it's
>        not doing unnecessary work (which would slow startup down), but
>        it *is* doing the *necessary* work to set up the environment (eg,
>        metacity needs to be intercepting MapRequest events, the panel
>        needs to map its windows with _NET_WM_STRUTS, etc) or else once
>        startup gets fast enough, we'll start to see race conditions.
>
>     4) In cases where early-started applications launch other
>        applications, make sure that this doesn't slow things down, and
>        if it does, see if they can be made to start those other
>        applications later than they do now.
>
> > will the new session code
> > (scheduled for 2.20) improve our situation in any way?
>
> It won't *automatically* improve anything; the big picture of startup is
> still the same. ("Start a bunch of programs. At certain points, wait
> until something is ready before continuing.") So if running
> gnome-keyring-manager very early in startup is the only way to have
> working keyring service in GNOME, then new-gnome-session is going to
> have to start it early just like old-gnome-session does. But any
> improvements we figure out for old-gnome-session will apply to
> new-gnome-session as well.
>
> -- Dan
> _______________________________________________
> Performance-list mailing list
> Performance-list gnome org
> http://mail.gnome.org/mailman/listinfo/performance-list