[Freeciv-Dev] Re: (PR#4073) Flow of graphics

["Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>]

On Thu, 24 Apr 2003, a-l@xxxxxxx wrote:

>
> I suggest removing all calls to flush_dirty() and simply setting it
> up as a timer of 30 milliseconds. Currently, at times when stuff
> happens, the client attempts to update the screen at a roaring rate
> of more than 500 frames pr second, in short bursts. That's just what
> happens when you write a game without relating to the fps concept at
> all "because it isn't Quake". This abuse is particularly notable when
> watching an autogame. Although this situation may not be the best
> target for optimization, it's still reasonable to look precisely at
> the times when Stuff Happens, as that's when the bugs creep out and
> disconnects may occur.
>
> - When you need a screen update, you never need it so badly that you
>   can't wait another 30 ms. The human eye will be happy still.
>
> - If the code makes more changes during that time, you just get a
>   bonus optimization, saving superfluous screen drawing.
>
> - Sure gdk drops events every now and then, but it's hardly noticable.
>
> I didn't count the times flush_dirty() was called and
> num_dirty_rects == 0. Counting that just adds some unneccessary
> function calls to the pot.
>
> This suggestion can also make animation work in a natural way.
> You could have a separate animation timer of 200 ms which does nothing
> but adjusting sprite pointers. If gdk drops the flush timer because of
> heavy load, some animation frames will simply be skipped gracefully.
> This gives really nice animation too, except that I can't draw
> something nice.

I see no problem imposing an upper limit for the update frequency as long
as you don't force the game to always redraw at that frame rate even if
there is nothing at all to refresh.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa