[Freeciv-Dev] city text , sdl widgets and rock & roll ( was Re: (PR#2858
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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
- [Freeciv-Dev] (PR#2858), Rafa³ Bursig via RT, 2003/01/19
- Message not available
- [Freeciv-Dev] Re: (PR#2858), Jason Short via RT, 2003/01/22
- Message not available
- [Freeciv-Dev] city text , sdl widgets and rock & roll ( was Re: (PR#2858) ),
Rafa³ Bursig via RT <=
- Message not available
- [Freeciv-Dev] Re: city text , sdl widgets and rock & roll ( was Re: (PR#2858) ), Jason Short via RT, 2003/01/23
- Message not available
- [Freeciv-Dev] Re: city text , sdl widgets and rock & roll ( was Re: (PR#2858) ), Rafa³ Bursig via RT, 2003/01/23
- Message not available
- [Freeciv-Dev] Re: city text , sdl widgets and rock & roll ( was Re: (PR#2858) ), Jason Short via RT, 2003/01/23
- Message not available
- [Freeciv-Dev] Re: city text , sdl widgets and rock & roll ( was Re: (PR#2858) ), Jason Short via RT, 2003/01/23
- Message not available
- [Freeciv-Dev] Re: city text , sdl widgets and rock & roll ( was Re: (PR#2858) ), Rafa³ Bursig via RT, 2003/01/24
|
|