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
