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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Feb 25, 2003 at 05:33:09AM -0800, Jason Short wrote:
> Raimar Falke wrote:
> > 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?
> 
> Because it is more correct this way?  Rafal put the flush_dirty calls 
> into the above two functions, but when I studied it closely it became 
> clear this was inferior.
> 
> Consider:

> Case 1.  The client receives a thaw_hint in the middle of a network 
> series.  It thaws and flushes.  Then we may receive more network data, 
> and we'll have to flush again.  We've just done an unnecessary flush.

So this is a performance thing.

> Case 2.  The client receives a series of packets, including a 
> freeze_hint.  But because of lag, it doesn't yet receive the thaw_hint. 
>   Now the network code exits.  Do we flush (obviously yes)?

I think (I have no data to backup) that this (doesn't got a
freeze_hint when exiting) is a rare event.

> The choice of when to draw is entirely client-dependent; there's
> nothing the server can do to help us with it.  We know to freeze
> when we enter the network loop and thaw when we exit it.  This
> differs from agents, which have to make queries and wait for their
> results...and (arguably) don't want to recalculate when we're about
> to get more data, even if there's no data there now.

The difference is that the agents can't cope with inconsistent
data. The data may be made inconsistent with one packet and fixed with
another. The two packets get wrapped in freeze/thaw. For the GUI this
inconsistent data doesn't cause a problem.


> Note that this is also the way queue_mapview_update works.
> 
> >>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.
> 
> Animation isn't drawn to the backing store; it is sent directly to the 
> window.  Moreover, it is handled entirely by the GUI right now.  We do 
> need a gdk_flush (or whatever) after each frame, but so long as we flush 
> everything else at the start we don't need to do it again midway (not 
> that it would hurt).
> 
> Later, if we develop a consistent framework for animation we may have to 
> rethink this.
> 
> >>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?
> 
> No, the two times are:
> 
> - Before we hand control back to the GUI main event loop.
> - Before any animation.
> 
> After the network code is only one case of #1.  For instance, when the 
> user clicks a mouse to recenter the mapview, we call 
> center_tile_mapcanvas and then we have to flush_dirty (except in gtk2). 
>   There are about 6 different cases where this type of thing is done 
> from the GUI code.
> 
> So, the long and complicated list traces the callers of 
> dirty_rect/dirty_all back toward the GUI main event loop.  At some point 
> in between the two, there needs to be a call to flush_dirty.  You can 
> verify that this is always the case.

This sounds cumbersome and error-prone. Can't we put a call to
gui_callback_finished in these callbacks which are called by the GUI?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The very concept of PNP is a lovely dream that simply does not translate to
  reality. The confusion of manually doing stuff is nothing compared to the
  confusion of computers trying to do stuff and getting it wrong, which they
  gleefully do with great enthusiasm." 
    -- Jinx Tigr in the SDM