[Freeciv-Dev] Re: different iso drawing algorithms

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Fri, 2002-12-13 at 12:24, Raimar Falke wrote:
> On Fri, Dec 13, 2002 at 03:02:23PM +0100, Rafa³ Bursig wrote:
> > Dnia 2002.12.13 10:35 Raimar Falke napisa³(a):

> Why do you insisted on a flush function which take a rectangle? It is
> unneeded. We can built the whole system on these two functions:

But I want to build it on only one function:

  flush_map_canvas(canvas_x, canvas_y, pixel_width, pixel_height);

The problem is that we are talking of two completely different things.

>   void mapcanvas_dirty_canvas_rectangle(canvas_rectangle);
>   void mapcanvas_dirty_flush(void);
> 
> Some wrapper functions for dirting map positions may be nice and
> required. So the users (packhand.c, control.c, ...) only have to dirty
> certain parts. Than million cycles later we found out that we got all
> data from the network. At this point we redraw all the regions we have
> dirtied before (call mapcanvas_dirty_flush). mapcanvas_dirty_flush
> can't and won't take a region of a canvas. This also means that no
> function will take a write_to_screen parameter anymore. The flow is
> like this:
> 
>   packhand.c:handle_tile_info calls
>   mapview_common.c: map_dirty_tile (this function can't calculate the
>                     canvas position since the map will be moved later,
>                     so it will save the map position in some list)
> 
> later
>  packhand.c:handle_freeze_hint calls
>  mapview_common.c:mapcanvas_dirty_flush which goes through the dirty
>                   lists (one for map positions and one for canvas
>                   rectangles) and creates a unique list of map tiles
>                   which need updating. Than it calls draw_tile
>                   (something like pixmap_put_tile or put_one_tile) for
>                   the dirty tiles. At the end it calls
>                   mapcanvas_update_screen (which is something like
>       get_canvas_xy(x, y, &canvas_x, &canvas_y);
>       gdk_draw_pixmap(map_canvas->window, civ_gc, map_canvas_store,
>                       canvas_x, canvas_y,
>                       canvas_x, canvas_y,
>                       width*NORMAL_TILE_WIDTH,
>                       height*NORMAL_TILE_HEIGHT);
> 
> For better efficiency mapcanvas_dirty_flush should maybe operate on
> tiles rectangles and not single tiles. This allows certain speed ups
> in the draw_tiles functions.

The system Rafal and I are talking about tracks which part of the
backing store are dirty, and need to be flushed to the screen.  Thus all
the flush() function (which may be internal to mapview_common) has to do
is flush the dirty parts to the display using flush_map_canvas.  This is
simple, and it is structurally similar to the current code.  But, it
requires that we do *all* of the drawing; the only place we save is on
writing to the display (which is huge).

Your system marks map tiles as dirty, so that they can be redrawn only
later.  Note that "flush" is not the right word here.  And your system
is not a replacement for ours, because you REALLY do not want to rewrite
the entire backing store to the display with every change.  It is a
longer-term goal IMO.

Note the current terminology is somewhat confused.  Right now we have:

  update = update something that has changed, maybe write_to_screen
  refresh = same as update

"flush" has the meaning that we're using it for.  What you're using it
for should be called "refresh" IMO - except that this is already
(confusingly) taken.

> Mhh thinking about this also leads to the conclusion that you _can't_
> pass canvas coordinates to the dirty functions since the canvas may be
> recentered. Only the map positions stay invariant/fixed. So the
> 
>   void mapcanvas_dirty_canvas_rectangle(canvas_rectangle);
> 
> from above needs to be changed to:
> 
>   void mapcanvas_dirty_tiles(int x, int y, int width_in_tiles, int 
> height_in_tiles);

How does this work in iso versus non-iso mode?  What is the rectangle
defined by it?

> > Each client should have own implementation of those functions. ( 1), 
> > 2), 3) )
> 
> I'm very sure that won't be the case. The implementation of
> mapcanvas_dirty_canvas_rectangle is GUI independent. So is a certain
> part (managing the list if dirtied rectangles) of
> mapcanvas_dirty_flush.

Rafal has said that gui-SDL can do it faster.  But I don't know if this
is because SDL can accelerate it somehow or just because he wants to use
SDL_Rect structures and so save on a few instructions of memory copying.

> I don't understand this. Maybe I don't want to understand it.

He is using the per-pixel method of flushing (which is good).  He is
hard-coding isometric loops in some places (which is good).  He is also
hard-coding a torus world (which is bad).

-----

Rafal: there are a couple of places where update_map_canvas() is called
that are neither a (1,1) square nor the entire visible canvas.  For
instance when removing a goto line we may redraw a (2x1) area.  So we
may be able to change things as you suggest, but first they need to be
moved into mapview_common.

jason