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: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#3424) New flush code
From: "Rafa≥ Bursig" <bursig@xxxxxxxxx>
Date: Thu, 27 Feb 2003 04:04:29 -0800
Reply-to: rt@xxxxxxxxxxxxxx

Dnia 2003.02.27 10:39 Jason Short napisa³(a):
> Raimar Falke wrote:
> > On Wed, Feb 26, 2003 at 04:35:16AM -0800, Jason Short wrote:
> >
> >>Raimar Falke wrote:
> >From the GTK page above:
> >
> > Example 2. Updating the GUI during a long computation
> >
> >     /* computation going on */
> > ...
> >         while (gtk_events_pending())
> >       gtk_main_iteration();
> > ...
> >     /* computation continued */
> >
> > I don't want to outwit the library. Both libraries provide a way to
> go a
> > layer deeper. With this extra control we can code a solution to the
> flush case
> > which is 100% correct and quite simple.
> The problem is it is not simple.  I've already given a specific
> example
> of how it can fail in a difficult-to-trace way.  The general problem
> is
> that this code should be kept localized, and should not depend on
> global
> changes done somewhere far away.
> Note, this "general problem" was a problem for the original
> architecture
> as well.  When you call center_tile_mapcanvas you have to know to call
> flush_dirty afterwards.  Fortunately, we can do better.
> >>One example is that gtk_main is re-entrant (although I doubt we use
> this
> >>feature).  If it were ever used, it would completely break the flush
> code.
> >
> > It would also break win32, mui and sdl. We would have to find an
> alternative
> > for these anyway.
> Why would a change to gui-gtk ever break gui-win32?
> >>In the worst case this could be done
> >>simply by adding a timeout with a timer of 0; gtk also supports this
> >>type of operation via gtk_idle_add().\
> >
> > This is also possible.
> Patch attached.
> I've added this form of support for GTK, XAW, and Win32, while
> removing
> the flush_dirty calls from these GUIs.
> 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.
No... Any new timers. SDL_AddTimer call new timer thread and as I know 
we can't do draw/update operation outside main thread.

Idea of puting flush_dirty is IMHO wrong.
I design this code to make flush after "list" draw operations called 
when is needed and not sequency flush.

But what happend if you have lag on net connection and order open city 
dlg. with stop move mouse or send input event.


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