[Freeciv-Dev] Re: different iso drawing algorithms

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Fri, 2002-12-13 at 23:52, Rafa³ Bursig wrote:

> Flush/refresh/update ( what name you want ) "copy" this buffer to 
> screen.( this take some time )

x11perf -copypixwin100
x11perf -copypixpix100

On my system, there was about a 15% slowdown writing to the screen
versus writing to another pixmap.  This is far less than I had thought. 
On Raimar's system there was about a 50% slowdown.

I also found that in iso mode about 35% of the drawing time was spent
drawing terrain and 35% was spent drawing roads/rails (in a high-tech
society).  I suspect using a two- or a three-layered system could cut
down hugely on the drawing time in most cases.  The "bad" case is where
the screen is recentered - in which case we have to redraw everything
unless we do something clever.


Or we could just go the direct route and remove the immediate problem. 
The attached patch increases drawing speed (on my system) for
update_city_descriptions() (the most common caller of
update_map_canvas_visible) by 5x under gui-gtk-2.0, and also improves
drawing quality.

The client-common part of the patch removes a significant inaccuracy in
the current queuing system; it is the gui-gtk-2.0 part that actually
codes the speedup.

I believe the speedup is about 4x because we avoid redrawing the tile
sprites, and an additional 1.25x because of the second level of
buffering (which avoids flicker: that flickering is slow!).

> > > > 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
> > 
> > flushing == coping from backing store to screen?
> > 
> YES
> > > hard-coding isometric loops in some places (which is good).  He is
> > also
> > 
> > This is good? IMHO not.
> > 
> This function is only to iso maps.

I do not think "iso maps" means what you think it means.

> > > hard-coding a torus world (which is bad).
> > 
> Yes and No.
> Yes: You have torus effect when you don't want it but only in 
> mapdrawing ( units can't move N-S ).

Indeed.

> No: x,y coordinate are always correct , you haven't to call evry time 
> "normalise_map_pos"

This is why it is really bad.  The method you use to wrap coordinates is
broken and will not work in the gen-topology case.  We have spent a lot
of time converting usages of map_adjust_x/map_adjust_y (which now remain
only in mapview_common.c) into normalize_map_pos.  This slows things
down but leads to code which is many times more flexible.

This is one of the more subtle problems with independent coordinate
wrapping.  Even if you use normalize_map_pos, you might be tempted to
write the loop:

  for (x = 0; x < width; x++) {
    int x1 = x + x0;
    for (y = 0; y < height; y++) {
      int y1 = y + y0;
      if (normalize_map_pos(&x1, &y1)) {
        /* ... */
      }
    }
  }

but this loop will not work in the gen-topology case.

I recommend reading up on this issue in the mailing list archives. 
There is a huge quantity of material.

jason

diff
Description: Text Data