[Freeciv-Dev] Re: Map coordinate cleanups.

[Jason Dorje Short <jshort@xxxxxxxxxxxxx>]

Raimar Falke wrote:
> 
> On Sun, Aug 19, 2001 at 01:04:39PM -0400, Ross W. Wetmore wrote:
> > The total run times for an exactly identical game show an overall
> > 25% cost (9 min vs 12 min) for functions over macros for a small
> > set of the common ones. One could probably refine this by playing
> > with the set to see which were the key ones.
> >
> > My thoughts at the moment are that this would be really useful for
> > client code that seems to have a performance bottleneck in processing
> > server packets that can cause it to die from buffer exhaustion. A
> > small speedup in the client might be enough to keep it ahead of the
> > wave.
> 
> The server is faster in sending out packets than the client can
> display the changes. I would suspect the improvements in the common
> code base would also benefit the server. The server justs wins this
> race. Maybe some of the gui (drawing) code needs to be examined.

I took a look at some of this code after Vasco explained the problem
before.

Right now essentially nothing is buffered client-side.  The client reads
in a whole buffer of information, which it then scans through packet by
packet.  However, no further reading is done until the whole buffer is
exhausted.  Thus the buffer isn't "buffering" at all, and making it
larger wouldn't help.

The problem and the reason the client is so slow is that it draws
graphics *slowly*.  This can be controlled by several "local options";
when I run an all-ai game and want to test out the GUI as well, I
generally set all options so that things go really fast and then I never
get disconnected.

What is needed, IMO, is a real form of client-side buffering.  This will
be tricky to do, but should not require threading as Vasco had
previously said.  When the buffer gets too large, the graphics should be
automatically sped up (somehow... [1]) so that the client can keep
pace.  Alternately, it could just be possible for the buffer to grow
indefinitely...and we can just hope that someday the client catches up.

Any "efficiency" changes that are made will affect the server far more
than the client, and so will only make this problem worse.

[1]  I suggest creating another global variable that has its value
initially set to 0 and increased depending on the size of the pending
buffer.  Then the GUI code can check this variable as well as the local
options in deciding what graphics/animations to draw.

jason