[Freeciv-Dev] (PR#7331) Speeding up the map view

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7331 >


The FS client supports dragging the mapview around with the right
mouse button. This requires a fast redraw of the map view when the
position of the map view is changed (I call this for now reorigin). So
far the speed isn't sufficient on my system (1.5 ghz). While PR#7297
turned out impossible here are two new ideas.

1) The whole visible map is cached (done currently by
mapview_canvas_store). Out of this any non-overlapping tiles are
reused in case of reorigin. Non-overlapping means here that tiles
which are at the border in an overlapping tileset can't be reused.

For this idea a second backing store has to be add. The first one
holds all the tile graphics. The second add the city descriptions and
maybe other decoration. The reason is that the placement of the city
descriptions depend whether the city is visible or not.

I started to implement this idea but gave up. This issue got more
complex that I imagined. You have to consider:
 - a lot of decorations (city selected, grid, borders, goto line)
 - unit movement
 - unit fight animations
 - flushing
It is hard to get this right.

One thing I learned however is that with the unified_overview2.diff
patch we can move the dirty/flush handling into common code.

2) Caused by the problems of 1) this approach is simpler, more easy to
get correct and should bring the same speed improvements. The idea is
the old one of sprite merging. You cache the results of the 

    for (i = 0; i < count; i++) {
      if (tile_sprs[i].sprite) {
        gui_put_sprite_full(pcanvas_store,
                            canvas_x + tile_sprs[i].offset_x,
                            canvas_y + tile_sprs[i].offset_y,
                            tile_sprs[i].sprite);
      }
    }

if we change this to let this cache be indexed by the position we can
cache the outcome of

    int count = fill_tile_sprite_array(tile_sprs, map_x, map_y, citymode,
                                       &solid_bg, &pplayer);
    int i = 0;

    for (i = 0; i < count; i++) {
      if (tile_sprs[i].sprite) {
        gui_put_sprite_full(pcanvas_store,
                            canvas_x + tile_sprs[i].offset_x,
                            canvas_y + tile_sprs[i].offset_y,
                            tile_sprs[i].sprite);
      }
    }

since fill_tile_sprite_array is also not a cheap function. So it would
be cache

 (x,y) -> struct *sprite

which is limited in size and have LRU (or some other) semantics. An
entry in the cache will be invalidated (read removed) if something the
this position changed.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "brand memory are for windows users that think their stability
   problems come from the memory"
    -- bomek in #freeciv