Re: [Nautilus-list] Nautilus Performance Analysis

[Darin Adler <darin bentspoon com>]

On Tuesday, August 14, 2001, at 07:08  PM, Michael Rothwell wrote:

> On 14 Aug 2001 10:30:51 -0700, Darin Adler wrote:
>
> > > it seems the jpeg reader is asking the OS to read tiny little bits at a
> > > time
> >
> > We are reading it with gdk-pixbuf. I imagine this is a bug in the
>
> It looks like Nautilus uses gdk_pixbuf_new_from_file() a lot. You can
> control the chunk size you're loading if you approach it another way.
>
> Read big chunks from another thread (gnome-vfs in the current case) --
> 64k or more at a time -- and then feed the chunk to
> gdk_pixbuf_loader_write(). You can have
> gdk_pixbuf_render_to_drawable[_alpha] get called via signals if you want
> to update a drawable as the image is loaded.

Right, the Nautilus developers are aware of the loader interface. We used 
it to implement eel_gdk_pixbuf_load, which is like 
gdk_pixbuf_new_from_file(), but uses gnome-vfs, and to implement 
eel_gdk_pixbuf_load_async.

But the eel functions do use a 4K buffer. I can up the buffer size to 64K 
and see if that helps.

> Currently, gdk_pixbuf_loader_write() is used only in
> nautilus-image-view.c

You overlooked the eel functions, I think.

Are you recommending that we always use our own eel_gdk_pixbuf_load, and 
avoid gdk_pixbuf_new_from_file? I think that the case that Alan was 
complaining about was in the image viewer, where we set the buffer size 
ourselves. I'm going to up the buffer size in both eel and in the image 
viewer to 64K rather than 4K, and I think this will help.

> Of course, using gdk_pixbuf_loader_write() also means that you can
> implement your own cache a little more cleanly, I would think.

I'm not sure what you mean. I don't think that the particular call you use 
to load the pixbuf has any effect on the caching you can do after loading 
the pixbuf.

    -- Darin