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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Aug 20, 2001 at 03:29:10PM -0700, Kevin Brown wrote:
> 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.

The only oddity I can spot is:
      /* first tile without mask */
      gdk_draw_pixmap(pm, civ_gc, tile_sprs[0]->pixmap,
                      0, 0, canvas_x, canvas_y,
                      tile_sprs[0]->width, tile_sprs[0]->height);
      i++;

But this looks superfluous since:
 - there would be undefined pixel if the mask of tile_sprs[0] isn't
 all 1's, since pixels where the mask is 0 aren't definied in the
 pixmap
 - so the mask must be all 1's and so the sprite tile_sprs[0] can be
 handled like every other sprite

> > > 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.

Ok.

> > > 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Microsoft DNS service terminates abnormally when it recieves a response
  to a DNS query that was never made.
  Fix Information: Run your DNS service on a different platform."
    -- MS service information on bugtraq