Re: [Nautilus-list] Nautilus Performance Analysis

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]