Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2004:
[Freeciv-Dev] (PR#9105) one final mapview optimization
Home

[Freeciv-Dev] (PR#9105) one final mapview optimization

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] (PR#9105) one final mapview optimization
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 25 Jun 2004 07:26:31 -0700
Reply-to: rt@xxxxxxxxxxx

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

There is one more mapview optimization that would give further speedups 
that will potentially really help with small scrolls (like gui-fs's 
grab-and-drag scrolling or a sliding mapview).

[In the below explanation I talk only about width.  However the exact 
same thing applies to height.]

Currently the mapview has a canvas store that is slightly independent 
from the mapview window itself.  The canvas store has a quantized width 
that is a multiple of NORMAL_TILE_WIDTH, so when resizing the mapview 
window a new store is only sometimes needed.  When updating a tile 
(e.g., the return value of map_to_canvas_pos) it must be updated 
anywhere on the store, not just on the window.  However when checking to 
see if a tile is in the interior region (e.g., 
tile_visible_and_not_on_border_mapcanvas) we're only concerned about the 
mapview window.

So much for background.  The thing is that when you move the mapview, it 
must have some tiles redrawn.  In the old days if you recentered it by 1 
pixel the entire mapview would have to be redrawn - unusably slow.  Now 
if you recenter it by one pixel to the right just that one column of 
pixels must be redrawn.  Of course this necessitates the redrawing of an 
entire column of tiles, and in iso-view this means two columns of tiles. 
  It's still slower than it could be.

Now for the next level of optimization.  Start by taking a look at the 
attached .png and .fig files.

I think the next level of optimization is to add extra padding to the 
store on the left as well as on the right.  We can then quantize the 
resolution of gui_x0.  We start by having a

   #define QUANTA (NORMAL_TILE_WIDTH / (is_isometric ? 2 : 1))

which can be tweaked later to give optimal results.  Now both sides of 
the mapview store must be aligned to this grid.  So if the _window_ has 
origin (gui_x0) and right edge (gui_x0 + width = gui_x1), the _store_ 
will have origin FLOOR(gui_x0 / QUANTA) * QUANTA and right edge 
(approximately) CEIL(gui_x1 / QUANTA) * QUANTA.

When the mapview scrolls, if it remains inside the store no redrawn need 
be done.  In this case we just have to copy the store to the mapview. 
However if the window moves outside of the store then we must move the 
store.  The width remains the same, and we just move the origin.

With the QUANTA shown above, no additional drawing will be required for 
updates.  Any tile that is on the store would be on the window anyway - 
the difference is that is't now all the way on the store, so it won't 
have to be redrawn if we move just a pixel or two.  With a larger QUANTA 
some extra redrawing is needed for updates, but it may still be faster 
because less redrawing is needed for scrolling.

jason

PNG image

image/xfig


[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] (PR#9105) one final mapview optimization, Jason Short <=