Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] (PR#8830) update_map_canvas is called way too much
Home

[Freeciv-Dev] (PR#8830) update_map_canvas is called way too much

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] (PR#8830) update_map_canvas is called way too much
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 24 May 2004 21:51:57 -0700
Reply-to: rt@xxxxxxxxxxx

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

update_map_canvas is called entirely too often.

No doubt this has been the case for a long time.  But now may be a good 
time to fix it, since only now does (almost) all drawing go through 
update_map_canvas.

For instance, with my current set of options (which includes the map 
grid on), if I change the freelog in update_map_canvas to LOG_NORMAL I 
can find such things as...


1.  A flickering focus unit:

2: update_map_canvas(pos=(223,118), size=(64,48))
2: last message repeated 2 times
2: last message repeated 2 times (total 4 repeats)
2: last message repeated 4 times (total 8 repeats)
2: last message repeated 8 times (total 16 repeats)
2: last message repeated 16 times (total 32 repeats)

This one's not so bad.  But if other units had idle animations we need a 
better way.


2.  Moving a unit:

2: update_map_canvas(pos=(223,92), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(255,108), size=(64,48))
2: update_map_canvas(pos=(223,92), size=(64,48))
2: update_map_canvas(pos=(287,124), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(255,140), size=(64,48))
2: update_map_canvas(pos=(287,124), size=(64,48))
2: update_map_canvas(pos=(191,108), size=(64,48))
2: update_map_canvas(pos=(223,92), size=(64,48))
2: update_map_canvas(pos=(255,108), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(191,140), size=(64,48))
2: update_map_canvas(pos=(159,124), size=(64,48))
2: update_map_canvas(pos=(191,108), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(191,140), size=(64,48))
2: update_map_canvas(pos=(159,156), size=(64,48))
2: update_map_canvas(pos=(223,156), size=(64,48))
2: update_map_canvas(pos=(223,156), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(223,124), size=(64,48))
2: update_map_canvas(pos=(287,156), size=(64,48))
2: update_map_canvas(pos=(255,172), size=(64,48))
2: update_map_canvas(pos=(159,156), size=(64,48))
2: update_map_canvas(pos=(191,172), size=(64,48))
2: update_map_canvas(pos=(223,188), size=(64,48))

You'll notice a few repeats here.  Of course the unit is being animated 
here with a bunch of frames; the time spent is user-controlled and 
should be constant.  In this case unit move animation time is 30ms. 
Most of these could be cut out, increasing the animation speed (=> 
number of frames) by a good factor.  (I think only 2 updates should be 
necessary.  Plus the animation, of course, which is just a few copies.)


3.  Moving a unit, with animation disabled:

2: last message repeated 30 times (total 62 repeats)
2: update_map_canvas(pos=(255,204), size=(64,48))
2: update_map_canvas(pos=(255,172), size=(64,48))
2: update_map_canvas(pos=(287,188), size=(64,48))
2: update_map_canvas(pos=(223,188), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(223,220), size=(64,48))
2: update_map_canvas(pos=(223,188), size=(64,48))
2: update_map_canvas(pos=(255,204), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(127,204), size=(64,48))
2: update_map_canvas(pos=(127,172), size=(64,48))
2: update_map_canvas(pos=(159,188), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(159,220), size=(64,48))
2: update_map_canvas(pos=(159,188), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(223,220), size=(64,48))
2: update_map_canvas(pos=(127,204), size=(64,48))
2: update_map_canvas(pos=(191,236), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(223,220), size=(64,48))
2: update_map_canvas(pos=(159,220), size=(64,48))
2: update_map_canvas(pos=(191,172), size=(64,48))
2: update_map_canvas(pos=(191,172), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(191,204), size=(64,48))
2: update_map_canvas(pos=(191,140), size=(64,48))
2: update_map_canvas(pos=(223,156), size=(64,48))
2: update_map_canvas(pos=(255,172), size=(64,48))
2: update_map_canvas(pos=(159,156), size=(64,48))
2: update_map_canvas(pos=(127,172), size=(64,48))
2: update_map_canvas(pos=(0,0), size=(510,386))

I especially like the last one (see #6 below).  This is basically 
unchanged when the map grid is turned off.


4.  Moving a worker:

2: update_map_canvas(pos=(159,81), size=(256,128))
2: update_map_canvas(pos=(246,161), size=(83,22))

Hey, this one's right!  One call to redraw the worker and another to 
redraw the city description.


5.  Adding something to the end of a city's worklist:

2: update_map_canvas(pos=(191,97), size=(256,128))

this one is disturbing because it makes me suspect that any time a city 
packet is received, the city text is redrawn.  Which is bad since the 
current network model is based on the assumption that you can safely 
send a packet many times, and only the "changes" will be sent.


6.  Sentrying a unit:

2: update_map_canvas(pos=(287,124), size=(64,48))
2: update_map_canvas(pos=(0,0), size=(510,386))

Enough said.  This one happens because the mapview window actually gets 
resized and so a total redraw is done.  The resize occurs because the 
panel text and graphics change and so the panel size changes slightly. 
Bad.  This is probably what happened with the unit move (#3) above as well.


7. Scrolling to the right (via scrollbar):

2: update_map_canvas(pos=(478,0), size=(32,386))

Again this is right.


8. Founding a city:

OK, I'm not even going to cut-and paste this one.  It involves 239 
single-tile, almost all of which are single-tile (64x48).  Of course 
each such redraw draws 9 separate tiles, each with a dozen or so 
sprites.  So we have to redraw TENS OF THOUSANDS of sprites when a city 
is founded.  This is beyond amazing.  We could get by with a single 
update() call.


9.  Dying:

Same as #8, not even worth listing.  In this case every tile on the 
mapview is redrawn many times.  The total is 1029 single-tile calls to 
update (from wc -l).  Hundreds of thousands of sprite draws.

2: update_map_canvas(pos=(511,0), size=(-1,48))

this update is entirely off of the mapview.  However because of a bug in 
the clipping within update_map_canvas it actually gets drawn.  And the 
drawing isn't a no-op since some of the tiles that overlap with this 
tile actually _are_ on the mapview.


10.  End-of-turn:

2: update_map_canvas(pos=(127,86), size=(256,128))
2: update_map_canvas(pos=(209,166), size=(92,25))
2: update_map_canvas(pos=(0,0), size=(510,386))

this is with one city and no units.  This is one redraw for the city 
grid, one redraw for the city text (entirely contained in the first one 
of course), and one redraw for no reason whatsoever.


11.  Apollo.

Comparable to #9.  This only seems to happen on the first turn, however 
(I guess delta just skips the packets entirely thereafter?  Or do we not 
get updates each turn in the default ruleset?).

In the past people have complained about how much network bandwidth this 
update takes.  Well, the network bandwidth is nothing compared to the 
redraw time...


12.  Making the mapview larger:

2: update_map_canvas(pos=(0,0), size=(514,386))

meaning this is a full redraw.  The tile_size has changed so some redraw 
is necessary.  But as in update_map_canvas it need only be very small.


13.  Making the mapview smaller:

Same as #12.  Of course in this case no update is needed.


Well, that should be enough for a while.

jason




[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] (PR#8830) update_map_canvas is called way too much, Jason Short <=