Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2005:
[Freeciv-Dev] Re: (PR#12634) ftwl: Rewrite main redraw loop (repost)
Home

[Freeciv-Dev] Re: (PR#12634) ftwl: Rewrite main redraw loop (repost)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: per@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#12634) ftwl: Rewrite main redraw loop (repost)
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Fri, 25 Mar 2005 04:27:09 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12634 >

On Fri, Mar 25, 2005 at 03:53:47AM -0800, Per I. Mathisen wrote:
> I found the problem with the SDL backend. SDL was innocent of all charges,
> and the same was the SDL backend code. Turns out the problem was that the
> redraw loop was ... pretty much non-existent. Basically there would be
> redraws at random intervals due to other stuff happening, but not as a
> result of actual map movement. The x11 backend had fixed this by inserting
> a call to the high-level sw_paint_all() function directly into the
> low-level backend code. The sdl backend did not have this incredible
> kludge.

> So, I decided to make a change I had long wanted, making ftwl a
> constant-frame-rate application. This is nice for doing animations. The
> framerate should probably be either user set or dynamic, depending on
> speed of graphics hardware, but so far a fixed FPS of 20 at least makes
> the graphics smooth pretty much irrespective of backend choice.

Sorry but I dislike this. FTWL (the library) is event driven. It
should redraw itself IFF this is required. Note that however that the
FTWL client may do something like this (constant redraw for
animations).

For the starting problem I propose something different. This is also
needed to implement the add_idle_callback().

be_next_event is splitted. The first part will return immediately. It
will fetch a queued event or return with no event. The second part
will waiting for the network or timeout.

Now the common FTWL code does something like:
  forever() {
    while(be_next_event_non_blocking()) {
      handle;
    }

    execute idle callback

    // to make the user happy because the next step may take some time
    sw_paint_all(); 

    be_next_event_blocking();
    handle;
  }

Do you know the best part? No changes to the backends are needed
because with the timeout feature of the existing be_next_event() we
can do the blocking and a non-blocking version already. Still it may
be cleaner to really create these two functions.

        Raimar

-- 
 email: i-freeciv-lists@xxxxxxxxxxxxx
 A life? Cool! Where can I download one?





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