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

[Freeciv-Dev] Re: (PR#3424) New flush code soplited in 2 parts

[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 soplited in 2 parts
From: "Rafa³ Bursig" <bursig@xxxxxxxxx>
Date: Sat, 15 Feb 2003 02:32:35 -0800
Reply-to: rt@xxxxxxxxxxxxxx

Dnia 2003.02.15 09:34 Raimar Falke napisa³(a):
> On Thu, Feb 13, 2003 at 04:50:59PM -0800, Rafa? Bursig wrote:
> >
> > Hi
> >
> > Next step to new buffer code in SDLClient.
> >
> > This is secound version of New Flush code.
> >
> > add_to_flush( x , y, w , h ) - save redrawed arrea in rect array.
> > flush_rects(void) - flush stored rects in one call.
> > add_all_to_flush(void) - save entire screen to flush and block
> adding
> > new rect to array untill flush_rects() funct is call.
> >
> > For All Clients ( exept SDLClient ) this give the same current
> > functionality becouse
> > add_to_flush( x , y, w , h ) function call flush_mapcanvas(x , y, w
> ,
> > h) and
> > flush_rects(void) , add_all_to_flush(void) are empty.
> >
> > In future Client Maintainers can make own flush code based on this
> > functions.
> >
> > But current SDLClient can use additonnal flush extensions.
> >
> > this code was split on two sub-patches :
> > 1) add new API functions and set basic functionality of this code.
> > 2) change all call of refresh_tile_mapcanvas(map_x, mao_y, TRUE) to
> >      refresh_tile_mapcanvas(map_x, map_y, FALSE).
> >
> > Secound wouldn't have any influenceon other clients becouse :
> > TRUE -> call flush_mapcanvas(x , y, w , h).
> > FALSE -> call add_to_flush( x , y, w , h ).
> 
> Naming: all three function should have the same prefix
> Coding-Style: read the guide.
>  +void add_to_flush( int canvas_x , int canvas_y ,
>                     ^            ^  remove these
>                     1             2

1) I still prefer name "add_to_flush" than "flush_add_to".

2) no... becouse this is "vital" name. This say you that you must put 
here screen position not map position.

This code don't care what do you flush : map tiles, city description or 
gui widgets it simply make screen area flush.

> Purpose: why do you remove the final flush_mapcanvas in
> update_map_canvas_visible only to add a call to flush_rects after the
> call of update_map_canvas_visible in control.c? Won't adding "bool
> write_to_screen" to update_map_canvas_visible be better here?
> 

Becouse flush_rects() is call in 
client/packhand/handle_processing_finished(void) and
client/packhand/handle_thaw_hint(void).
AND THIS I MAIN VITAL CALLs OF FLSH_RECTS().

you get flush of update_map_canvas_visible after last package come but 
problem is with all client inside redraw actions without net access and 
that is reason I put flush_rects() into control.c and in some other 
places.

If you put flush_rects() at end of update_map_canvas_visible then flush 
is made after redraw map and redraw city descriptions but sdl client 
have additional widget layer which is redrawed with other net packages.

if you focus to next unit then :
- recenter map or redraw old and new unit ( you want flush here )
- redraw unit info window ,order_butons, etc.
- flush at end foncus to next unit net connection.

In this way you for moment (depend on CPU and net lag) see new unit on 
map and desciption of old unit.

Other client are secure of this becous they current don't use this 
method and make flush dirrect in update_map_canvas_visible. 
(add_to_flush( x , y, w , h ) == flush_mapcanvas(x , y, w , h))

Rafal




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