Re: [Nautilus-list] throbber out-of-process

[Havoc Pennington <hp redhat com>]

Darin Adler <darin bentspoon com> writes: 
> We had an in-process throbber. It wasn't throbbing enough to the point
> that people thought that Nautilus was completely broken.
> 
> So Andy made the out of process throbber. I said at the time that I
> would have preferred to fix the places where Nautilus locks
> up. Nautilus was designed so that it should basically never lock
> up. It should always be another thread that blocks, not the main one.
> 
> I'm not sure where you get the idea that Nautilus doesn't get stuck as
> much as it used to. Do the recent changes really make Nautilus get
> stuck so much less? I think there are all sorts of things that make
> Nautilus lock up more than it should.

I don't have a sense that it freezes up much. Once a window is open,
it generally seems pretty snappy. The icon view is blazingly fast in
fact.

Overview of problems we are noticing with Nautilus right now:

 - occasional crashes; one in GConfClient somewhere that I believe is
   a double free, one I was seeing in gnome-vfs file method that I
   couldn't figure out, and things like get_metafile() and
   get_factory() and other CORBA calls will fail from time to time and
   people were evil and didn't check errors. These are more common 
   in the sidebar panels. I tried to change them to at least print 
   the error and exit instead of segfaulting.

   I want to spend more time debugging these - all the crashes I'm seeing
   are only erratically reproduceable, and never when I have debug
   symbols. ;-)

   Stability is pretty good in general though, I don't see crashes 
   all that often.

 - opening a new window and starting up Nautilus is still too slow.
   The problem may be the same, since starting up involves 
   creating windows. Oddly, if you "nautilus -q" the session manager
   will respawn Nautilus almost instantly; I don't know what's 
   different about this case vs. the normal startup/window-open.
   But when respawned, Nautilus will be back in only a second or two. 
   Perhaps it's already paged in and simply sucking all the code off 
   disk is our main speed problem!

   We have hit a wall on improving this, because the available
   profilers simply suck too much. We need something that can give a
   multiprocess/multithread view of what is going on.  The profiles we
   can get are just jumbles of assorted small stuff. Sadly a decent
   profiler and a platform it will run on is really expensive.

   The fixes we've made to eliminate background of none and expose
   handling on the desktop dramatically decrease user perception of
   "brokenness" on startup, at least. When people get bored on startup
   and start making "window trails" they get a bad impression and file
   tons of bug reports.

 - the memory footprint is a bit too high. I haven't profiled this to
   see what can go. It's not that bad, but it's not as good as it
   should be yet.

   I'm hoping that with GTK 2 we can nuke the whole smooth font
   subsystem, nuke things like EelImageChooser, and just generally
   blow away a bunch of code in favor of stock stuff. This should
   shrink the footprint, reduce maintenance burden, and get
   i18n/keynav/accessibility to work with fewer headaches.

   Of course some GTK things have gotten slower, so maybe it'll 
   just all wash out.

 - Between GTK 1.2 and out-of-process components, opaque resizes 
   are a disaster. Not really fixable for now, sigh.

There are also some UI tweaks we'd like to do, jrb is trying to fool
with dnd, etc., though we are pretty frozen in this respect for this
release (you probably saw the beta go out this morning).

Havoc