Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: GTK client draws more slowly than it needs to
Home

[Freeciv-Dev] Re: GTK client draws more slowly than it needs to

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Kevin Brown <kevin@xxxxxxxxxxxxxx>
Cc: bugs@xxxxxxxxxxxxxxxxxxx, "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: GTK client draws more slowly than it needs to
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Aug 2001 08:31:20 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Aug 19, 2001 at 03:21:36PM -0700, Kevin Brown wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> 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.
> 
> Ahh...and here you are indeed correct: the drawing code can be sped up
> a bit.
> 
> Attached is my GTK+ client speedup patch as it stands right now.  It
> creates and uses a tile cache.  Activate it with --use-tile-cache.
> You'll need to apply my client-specific argument handling patch from
> PR#892 before you apply this patch.
> 
> It provides the options "--tile-cache-size", which allows you to
> control the number of entries in the cache (default 1024) and
> "--min-cached-tile-depth", which allows you to control the minimum
> number of sprites that have to form a tile before it'll be cached
> (default is 2).
> 
> Note that this does NOT affect isometric view.  I'm still working on
> that one, as it will require me to combine masks (but once I've got
> that done it'll be a lot more general-purpose).  So to test this,
> you'll have to use "--tiles trident" or something similar.
> 
> Because of how it works, this won't help that much unless you have fog
> of war turned on.  But it should help significantly in that case.
> 
> 
> I'm submitting this to bugs@xxxxxxxxxxxxxxxxxxx as well, in the hope
> that it'll create a PR# for this...
> 
> I'll be very interested in knowing how much it helps the problem of
> the client keeping up with the server, if any...

Looking at the code I noticed some things:
 - take a look at common/hash.[ch]
 - you should say what is key and what is hash in the cache
 - _I_ would make the key a NULL terminated array of pointers to
 sprites. This would also make sure you can be sure that you got the
 correct entry.
 - you may take a look at the sma3.diff.gz in ftp.freeciv.org
 especially the merge_sprites() method and the changes I made to
 tilespec.[ch]. I hope to get this included in maintree. This could
 make the cache benefitting all GUIs.

> +  tile_cache = malloc(tile_cache_size * sizeof(*tile_cache));
> +  if (tile_cache == NULL) {

fc_malloc will handle this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Q:  Do you know what the death rate around here is?
 A:  One per person.


[Prev in Thread] Current Thread [Next in Thread]