Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2004:
[Freeciv-Dev] Re: (PR#7385) overview isn't updated
Home

[Freeciv-Dev] Re: (PR#7385) overview isn't updated

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#7385) overview isn't updated
From: "Jason Dorje Short" <jdorje@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 9 Feb 2004 13:15:00 -0800
Reply-to: rt@xxxxxxxxxxx

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

Raimar Falke wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7385 >
> 
> On Sun, Feb 08, 2004 at 11:19:01AM -0800, Jason Dorje Short wrote:
> 
>>>The problem is much worse. The overview isn't updated at all (except
>>>for expose and recentering). A clear sign that I rushed the patch too
>>>much and so it got too less testing.
>>>
>>>The fix is to draw (copy to screen + white rectangle) the complete
>>>overview at unqueue_mapview_updates.
>>
>>That's definitely not "the" fix; it's horribly inefficient. 
> 
> 
> I agree that it is more inefficient then it could be.

Yah.

>>unqueue_mapview_updates may be called many times because if there's 
>>nothing to be done it's not supposed to do anything.  But if it always 
>>copies the _entire_ overview to the screen then it becomes quite slow.
>>
>>For instance this function is called before each animation.  Do we 
>>really need to redraw the overview each time?
> 
> 
> Alternative suggestions:
>  - a flag which is set every time the overview (backing store) is
>  updated and cleared when the backing store is copied to the screen
>  - perform the graphical operation we do to the backing store also to
>  the window. This is what the old code did. However there is a problem
>  and I'm not sure if this was a bug in the old code or the old code
>  too some measures to prevent it: the overview rectangle will be
>  destroyed this way.

This is a bug, but trivial.

> I'm for the first alternative. It also resembles what we do with the
> main mapview.

We shouldn't have to copy the _entire_ backing store all at once.  It 
should be possible to do a partial flush.  However here we run into the 
problem of redrawing the overview rect.  This is no problem when we're 
just updating one tile at a time, but if we flush half of the window in 
an expose event it's no good.

Leaving that aside for a minute, I think something like the first 
alternative would be good.  But I'd do it differently, with 
dirty_overviewcanvas.  The flush should be done inside flush_mapcanvas. 
  This will work very nicely for gui-gtk2 where all the work is done by 
GDK.  Other GUIs will just need an extra flag.  The time saved because 
we don't do piecemeal updates should more than make up for the extra 
work because we sometimes have to do full updates instead of one-tile 
updates.

jason




[Prev in Thread] Current Thread [Next in Thread]