Re: final speedup patch ...

[Federico Mena Quintero <federico ximian com>]

El sáb, 15-12-2001 a las 09:16, Michael Meeks escribió:

> 	I just committed this - a cleaned up version of last night's
> stuff. It should substantialy improve the performance of Nautilus and
> gnumeric, and certainly improves evolution performance markedly [ more so
> in conjunction with the previously posted evolution patch ].
> 
> 	So - I need it hammering on; perhaps now is your time to win glory
> by finding the heinous bug in it; can anyone that builds bonobo from CVS
> update and give it a go ?

While this makes for a fine optimization on a local display, it does not
help much with the particular problem we are having, to wit:

	1. Run Evolution on a remote display.

	2. Double-click on a message in the message list.  This wil
	   open a new window with the message in it.

On a remote display, this takes about 3 seconds on a clean 10 megabit
link.  It can be much worse on a busy link.

The problem happens because with the new window, all of the pixmaps must
be transferred to the server.

The general problem is that you are not making use of the resources that
you already have in the server.  Bonobo-UI may already have rendered a
pixbuf (a client-side resource) and drawn it to a pixmap (a server-side
resource), but it never re-uses pixmaps.  It just re-renders the pixbufs
and re-sends them to the server, creating new pixmaps.  Sending the data
is slow.

In general, you should not need to render a particular pixbuf more than
once unless you have a purging cache.  You just have to keep the pixmaps
on the server and switch between them as appropriate.

E.g. render the normal pixbuf for the FooCommand, send it to the server;
this creates pixmap A.  Render the insensitive pixbuf for the FooCommand
and send it to the server; this creates pixmap B.  In the future, when
the state of FooCommand changes, switch between pixmaps A and B as
appropriate --- they are already in the server, so you don't need to
render anything or send it over the wire.

  Federico