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

["Rafa³ Bursig" <bursig@xxxxxxxxx>]

Dnia 2003.02.15 19:24 Raimar Falke napisa³(a):
> On Sat, Feb 15, 2003 at 09:20:59AM -0800, Jason Short wrote:
> > Raimar Falke wrote:
> > > On Sat, Feb 15, 2003 at 02:32:35AM -0800, Rafa? Bursig wrote:
> > >
> > >>>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".
> > >
> > >
> > > What do you think about:
> > >
> > > flush_add_region
> > > flush_add_all_as_region
> > > flush_all_regions
> >
> > I prefer:
> >
> > dirty_rect
> > dirty_all
> > flush_dirty_rects
> 
> s/rect/rectangle/ or
> s/rect/region/ if you want it short.
> 
> Prefix with mapcanvas_?
> 
rather dirty_... is shorter :)

> > which is far more descriptive than "add_to_flush"...
> 
> Yes.
> 
> > >>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.
> > >
> > >
> > > I know. I proposed to change
> > >   void update_map_canvas_visible(void)
> > > to
> > >   void update_map_canvas_visible(bool write_to_screen)
> > >
> > > And add
> > >   if(write_to_screen) {
> > >     // call flush function
> > >   }
> > > at the end of it.
> >
> > Under these patches, the write_to_screen parameter doesn't really do
> 
> > anything anymore.  Whatever value it has, the client is likely to
> just
> > mark the area as dirty and flush it later.  The core issue is that
> every
> > drawing operation should be written to screen; the only qeustion is
> > when.  With the introduction of flush_dirty_rects this question is
> answered.
> 
> I want to add it since a lot of callers of update_map_canvas_visible
> would call mapcanvas_flush_dirty afterwards. Another alternative is a
> new function update_map_canvas_visible_and_flush. Just look at it as a
> chance to channel a common code pattern into a function or parameter.
> 

   Problem of call flush_rects/flush_dirty_rects/mapcanvas_flush_dirty 
has pure inside client action aspect. But I still prefer simple way to 
fix it.

Just call when it is needed and IMHO adding 
update_map_canvas_visible_and_flush to client API is wast of code jup 
,this function simple call 2 function and return and as I know can't be 
inlined.

If client maintainer deside that He need such function then he define 
it but it should stay in client-gui side.

Rafal