Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#3424) New flush code

[Freeciv-Dev] Re: (PR#3424) New flush code

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bursig@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3424) New flush code
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Tue, 25 Feb 2003 05:10:01 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, Feb 24, 2003 at 11:45:51PM -0800, Jason Short wrote:
> OK, here's a new version - a candidate for a final patch.
> I did a full audit of the places where dirty_rect/dirty_all was called, 
> and traced them back to ensure that flush_dirty was called afterward. 
> The result is that a lot of flush_dirty calls had to be added to the GUI 
> code - but I'm now pretty confident of the correctness.

> Another change is that instead of calling flush_dirty in thaw_hint and 
> handle_server_processing_finished (or whatever it's called), we instead 
> call it when we leave the network loop - from within 
> unqueue_mapview_updates.

What is the reason?

> In the future, queued updates can be used more extensively to avoid
> unnecessary redrawing; that will work in sync with the flush code.

> There are two fundamental times when we need to flush:
>   - After doing anything, before passing control back to the GUI loop.

>   - Before doing any animation.

I would expect after each frame.

> To verify that the second is done correctly, we need to find all instances of
> animation and make sure flush_dirty is called before entering them.  To
> verify the second, we can follow the trail of callers of dirty_rect and
> dirty_all to make sure every possible trail calls flush_dirty.  Note that in
> some cases (i.e., gui-gtk-2.0) the GUI will do this for us automatically and
> we don't have to worry about it.
> Note that we do _not_ need to worry about freeze/thaw hints from the server.
> This updating is an entirely GUI-side issue.  Here it differs from agents,
> for instance, which often rely on server queries to do their work (and don't
> want to "thaw" just because control is being returned to the GUI).
> Most of the time when we want to write to the screen, we should call
> unqueue_mapview_updates() directly.  This will fully update everything, and
> flush.  It is also forward-compatible with future drawing optimizations (see
> the note at bottom).

[ snip long and complicated list ]

What does this list tell me? You said above that there are two times
when flush is called: after the network (easy to implement) and during
animation (we have animation for unit combat, unit movement and
mushroom). So what is the reason for this list?


 email: rf13@xxxxxxxxxxxxxxxxx
 A life? Cool! Where can I download one?

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