[Freeciv-Dev] Re: GTK client draws more slowly than it needs to (PR#899)

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Aug 20, 2001 at 02:29:36PM -0700, Kevin Brown wrote:
> > Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > How large will the cache get, if it doesn't get pruned? It should be
> > > possible to prune a hash if it gets above a certain limit.
> > 
> > The cache is fixed in size, set either by default to 1024 entries or
> > whatever you specify with --tile-cache-size.
> 
> I know. But what happens if you set the size really high like 100000
> and play a bit. How much cache entries will be used?

My limited testing indicates that the cache usage is around 25 to 33
percent when number of entries is 1024, but I haven't done extensive
testing on a highly-populated map or anything.

Note that it doesn't bother to cache tiles composed of less than
min_cached_tile_depth (default 2), so many of the tiles you see on the
screen won't be cached since they're just single sprites.

> > Most importantly, however, is that how the sprites get combined
> > depends on some of these values, so it's not just a straightforward
> > tile combination right now (wish it were!).
> 
> So leave out isometric in the first version.

Okay, I can do that, but the point still remains.  Even for overhead
view, how the tiles are combined depends on these factors, so a
combine_sprites() function wouldn't be quite as useful as you might
expect with the code the way it is right now.

> > That being the case, it's not clear how much of a benefit I'd get from
> > storing the key.  Right now I just store the hash value (prior to the
> > mod) itself in the cache along with the tile so that if there's a
> > different hash value that gets me the same slot, I can detect the
> > collision.
> > 
> > And what should MAX_SPRITES be set to?  The number of sprites that
> > build up a tile can potentially be quite large.  
> 
> > Each unit you put onto a tile increases the number of sprites
> > associated with it, right?
> 
> No. From client/tilespec.c:fill_tile_sprite_array():
> 
>     punit = get_drawable_unit(abs_x0, abs_y0, citymode);
>     if (punit && (draw_units || (draw_focus_unit && pfocus == punit))) {
>       sprs += fill_unit_sprite_array(sprs, punit, solid_bg);

Ah, good.  So the only unit sprite it puts in the list is the one
currently in focus or the one that's currently viewable.

> > If we don't do all the sprites at once, then multiple calls have to be
> > made to merge_sprites(), which means that allocation of resources on
> > the X server (of GCs if nothing else) happens every time.  Depending
> > on the situation, this could slow things down considerably.
> 
> I still like the idea of encapsulate the gui-specific code in a
> method. The GC and other stuff can be done at some init time or as
> static method variables.

I completely agree with the concept (of making as much of this
gui-independent as possible), but I'm not sure how easy that'll be in
practice.  My first pass is GTK-specific.  Let me get that completely
worked out and I'll look harder at doing this in a GUI-independent
fashion.

> > It's not terribly common, but it does happen.  It happens often enough
> > that I noticed drawing artifacts when I used my tile cache for tiles
> > built from differing-sized sprites.  It's why I started thinking about
> > how to combine masks.
> 
> I would like to see such a all-in-one combine_sprites to compare the
> size and extra complexity to merge_sprite.

Okay, I'll build it and post it here.  But I think you'll find that
the complexity isn't as bad as you might expect.


-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.