[Freeciv-Dev] city text , sdl widgets and rock & roll ( was Re: (PR#2858) )

["Rafa³ Bursig via RT" <rt@xxxxxxxxxxxxxx>]

Dnia 2003.01.23 02:45 Jason Short via RT napisa³(a):
> Rafa³ Bursig via RT wrote:
> > This patch fix some problems with redrawing GUI widgets in
> SDLClient.
> >
> > All widgets are part of map and must be redraw after redraw of map,
> > lastest unification of draw code make this redraw imposible inside
> gui code.
> >
> > This function replace "show_city_descriptions()" in
> > "update_map_canvas_visible()" and all clients use it like wraper to
> > "show_city_descriptions()" funct.
> 
> The problem is that some graphics aren't buffered when they're drawn -
> 
> they are drawn directly onto the screen.  In the case of city
> descriptions, this is enforced in the common code by the order of the
> drawing.  (Other graphics are drawn directly as well, but only in the
> GUI.)
> 
> As long as this is the case, there will be problems.  We can introduce
> 
> workarounds for them on a case-by-case basis, but the workarounds
> generally have disadvantages.  The SDL client has the biggest problem
> since the map widgets, even with a redraw_map_widgets() function, will
> 
> flicker every time they're drawn.  This is quite noticable.
> 
> Another workaround is that show_city_descriptions is called for every
> expose event (in clients for which this makes sense).
> 
> I'm now convinced that the solution is to say all drawing done by the
> client-common code should be buffered.  We leave the decision of how
> to
> do the buffering up to the GUI.
> 
> Thus in update_map_canvas_visible, the current order is:
> 
>    update_map_canvas(..., TRUE); // writes to display
>    show_city_descriptions(); // also writes to display
> 
> whereas it should be
> 
>    update_map_canvas(..., FALSE); //doesn't write to display
>    show_city_descriptions(); // doesn't write to display
>    flush_mapcanvas_full(); // writes to display
> 
> This works out well for everyone.  It cuts down on flicker and speeds
> up the drawing process in normal cases.  For the SDL client, it means 
> you
>  can simply draw the map widgets on top of the canvas when it is
> flushed.
It isn't so simple in SDLClient case.

" surface == sprite "
" 8bit surface == surface with 8bit pixel coding -> 256 colors"
" 16bit surface == surface with 16bit pixel coding -> 65k colors"
" 32bit surface == surface with 32bit pixel coding ->  depend on ALPHA 
chanel -> >= 16M colors"

SDL can't on X create Surface in Video memory ( SDL_HWSURFACE - only 
DGA can this -> root -> use 2D hw accell. ) all surface are creates in 
system memory (SDL_SWSURFACE -> no 2D hw accell. ).

When I use X video output init main screen will created SW surface ( 
with size of phisical screen ( fullscreen mode ) or ordered size of 
window ( windowed mode ) ) which is equivalent of framebuffer. This is 
automaticaly "buffer" of screen but not "full".

I think that other enviroments like gtk use the same method ( all is 
draw to main buffer and then make flush entire buffer to display but 
this is almost hidden in API )

SDL on Windows (DirectX) is other story :( ( full framebuffer access -> 
2D hw accell )

When you draw somthing on screen/buffer you must update those changes 
to real screen.
Till now this one buffer was enought to SDLClient ( by using locking in 
some draw functions ) but lastest unification move most draw code 
outside gui depended code which force me to use the same method of 
buffering like "others" clients. ( but this rather slowdown drawing )

TODO:
I must create secound buffer to map with cities and units ( with is 
almost identical to main buffer )
without city text and widgets.

I don't like idea of next buffer for city text or widgets I rather 
prefer that those are drawed after "flush" map buffer directly to main 
buffer and then make "update" main buffer to video mem.

I propose that update_map_canvas_visible() has :

     /* fill map buffer with copy to main buffer  */
     update_map_canvas(..., TRUE ); // write to main buffer/display 
(SW) but not update video mem

     /* draw city text on main buffer */
     show_city_descriptions(); // write to main buffer/display (SW) but 
not update video mem

     flush_screen(); // update screen ( write SW main buffer to video 
memory )

or
     /* fill map buffer with copy to main buffer  */
     update_map_canvas(..., TRUE ); // write to main buffer/display 
(SW) but not update video mem

     /* draw city text on main buffer */
     update_city_descriptions( FALSE ); // write to main buffer/display 
(SW) but not update video mem

     flush_screen(); // update screen ( write SW main buffer to video 
memory )

where
GUI side function !
/* or update_map_widgets( bool clear ) */
void update_city_descriptions( bool clear )
{
   if (clear)
   {
      /* copy map buffer to main buffer */
   }

   /* draw city text on main buffer */
   show_city_descriptions();

  /* here I can put widget redraw code or other magic */

   if(clear)
   {
     flush_screen(); // update screen ( write SW main buffer to video 
memory )
   }

}

>   Eventually, you'll want to introduce a second layer of buffering to
> avoid the widgets flickering every time this happens.
> 
> The attached patch accomplishes this in the simplest way.  It does not
> 
> introduce a flush_mapcanvas_full, but just flushes the canvas using
> the
> existing function (which often will give off-screen coordinates).  It
> would be possible to add a write_to_screen parameter to
> show_city_descriptions() and show_city_desc(), but this is probably
> overkill (although it does make changes like this easier in the
> future).
> 
> It is tested under all clients other than MUI.
> 
> Although a rather short patch, this is a non-trivial design change.
> Are there any disadvantages of having the city descriptions be 
> buffered?
> 
If I have next buffer to city text or widgets then this buffer must be 
32bit surfaces becouse all city text and widgets use ALPHA chanel. City 
text use AA and are full 32bit surfaces and widgets have screen bit 
coding but have global alpha variable.

And this slow down drawing if screen has 8bit and 16 bit pixel coding.
( almost all video card use 32bit insteed 24bit ( totaly horror ) but 
this give lose 8bit per pixel (without alpha) or rgb is 10 12 10 )

Fastest draw is when both surfaces ( "src" and "dst" ) has the same 
pixel coding.
(SDLClient convert all loades graphics to screen format )

Rafal

----------------------------------------------------------------------
Poczta nowych mozliwosci >>> http://link.interia.pl/f16bc