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

[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: Fri, 28 Feb 2003 02:56:30 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Fri, Feb 28, 2003 at 12:37:46AM -0800, Jason Short wrote:
> Raimar Falke wrote:
> > On Thu, Feb 27, 2003 at 01:12:43PM -0800, Jason Short wrote:
> > 
> >>Jason Short wrote:
> >>
> >>>Raimar Falke wrote:
> >>
> >>>It seems reasonable to take this a step further and do it the same way 
> >>>for gui-sdl.  I believe this can be done with SDL_AddTimer, but I'm not 
> >>>familiar enough with the code to write this.  If that were done then all 
> >>>GUIs (except MUI which just has stubs) would be supported, and we could 
> >>>remove all flush_dirty calls from the common code except for the 
> >>>animation ones.
> >>
> >>New patch attached.  This has now been tested under gui-sdl and 
> >>gui-win32 as well.
> > 
> > 
> > GTK2 and GTK1 have different implementations. Any reason for this?
> 
> Because gdk-2.0 is cool and does all the work for us.  gdk-1.2 does not, 
> so we have to do it ourselves.
> 
> > GTK1 and win32 have almost the same implementation. Can't this be
> > unified?
> 
> It's not worth it - it would only save a couple of lines of code and 
> wouldn't really simplify the code flow.  We would need a new GUI 
> function: gui_enqueue_event(...) which queues a function for callback. 
> In return we could add new code real_dirty_rect and real_dirty_all to be 
> used by these GUIs...but since most other GUIs wouldn't use them they 
> would just be confusing for those authors.
> 
> > While I didn't search you may tell me which calls to
> > refresh_tile_mapcanvas(..., TRUE) are remaining?
> 
> There are a few left in the GUI code; none of these have been changed.
> 
> If we use the auto-event-flushing method from the most recent patch, we 
> can easily change all write_to_screen values to FALSE.  I did not do 
> that initially because it required more GUI changes.  We could also 
> still do this in two patches: one to introduce the flush code, the 
> second to change all of the write_to_screen values.

> One problem is that the SDL event code I used is unreliable.  Apparently 
> SDL can drop events, particularly before the main loop is entered. 
> After one dropped event the code cannot recover.  A good partial 
> solution would be to move the is_flush_queued=FALSE line into 
> flush_dirty for SDL and possibly other GUIs.

Are you sure the SDL drops events? Can you prove it? Normally it is
wrong usage.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Any sufficiently advanced technology is indistinguishable from magic."
    -- Arthur C. Clarke




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