[Freeciv-Dev] Re: (PR#2509) unification of update_map_canvas
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Dnia 2002.12.08 00:14 Jason Short via RT napisa³(a):
> On Sat, 2002-12-07 at 08:05, Rafa³ Bursig via RT wrote:
>
> > I don't like it. (This code extort on sdlclient whorse flush metod )
> > I prefer solution when "write_to_screen" go to
> > put_one_tile/put_one_tile_iso parms. And each client make his own
> > buffering method.
>
> Each client can make its own buffering method. What this change does
> is
> help to separate the flushing of the buffer from the drawing of the
> buffer.
>
> We don't want to propogate write_screen to put_one_tile. This will
> give bad results when we draw more than one tile at a time.
>
No , but wait...
> The drawing system the SDL-client uses is broken. The buffering it
> does is fine, but ignoring the write_to_screen parameter will not
> work. It
> makes it impossible to keep everything updated (city names, map grid,
> moving units, etc). This problem must be fixed in the core, and to do
> so flush_screen can help.
>
> I think if gui-sdl just gives proper implementations of all these
> functions, we can address the problems in the core and all clients
> will
> benefit.
>
flush_screen is needed but not enough to support all cases.
We need 4 functions :
1) flush_screen(void) - flush whole screen. After entire screen has
been redrawed.
2) flush_rect(x,y,w,h) - flush one screen area. Will be used with
animation or other cases when only one tile will be drawed on screen.
3) save_flush_rect(x,y,w,h) - save rect in list/array.( flush_rects
funct. will fush them )
4) flush_rects(void) - flush saved list/array of rect. Should be used
with sequence of drawed tiles ( exp: unit moves draw several single
tiles that can be flushed in one call )
> The best long-term solution IMO is to get rid of the write_to_screen
> parameters entirely (i.e., make them all FALSE). Thus no writes go to
> the screen until a flush() is propogated. But this may not work for
> animation; we haven't quite gotten that far yet.
>
write_to_screen should stay but can work litle different
if ( write_to_screen )
flush_rect(x,y,w,h); /* animation */
else
save_flush_rect(x,y,w,h);
There is only problem, where and when call flush_rects funct.
In SDLClient I use for that queue_mapview_update funct. (not only )
becouse is call after last packet "arrive".( exp: unit stop move
seqence from one tile to next tile )
( that is the major reason why draw code stop work becouse
update_map_canvas_visible did only souch flush )
> In any case, I don't want to give the SDL client special preference
> just
> because it uses a workaround for the current drawing inefficiency in
> the core code.
>
Yes it is true that SDL can speed up such "flush_rects" updates.
But gtk clients has special preference in network code and nobody
protest.
Problem is that diferent enviroments has some own preferences and why
we sholdn't use them only becouse other enviroments can't.
Rafal
----------------------------------------------------------------------
Powiedz sobie dobre "Dzien dobry"! >>> http://link.interia.pl/f168b
|
|