[Freeciv-Dev] Re: (PR#7331) Speeding up the map view

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7331 >

On Tue, Jan 27, 2004 at 04:48:58AM -0800, Raimar Falke wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7331 >
> 
> 
> The FS client supports dragging the mapview around with the right
> mouse button. This requires a fast redraw of the map view when the
> position of the map view is changed (I call this for now reorigin). So
> far the speed isn't sufficient on my system (1.5 ghz). While PR#7297
> turned out impossible here are two new ideas.

> 2) Caused by the problems of 1) this approach is simpler, more easy to
> get correct and should bring the same speed improvements. The idea is
> the old one of sprite merging. You cache the results of the 
> 
>     for (i = 0; i < count; i++) {
>       if (tile_sprs[i].sprite) {
>       gui_put_sprite_full(pcanvas_store,
>                           canvas_x + tile_sprs[i].offset_x,
>                           canvas_y + tile_sprs[i].offset_y,
>                           tile_sprs[i].sprite);
>       }
>     }
> 
> if we change this to let this cache be indexed by the position we can
> cache the outcome of
> 
>     int count = fill_tile_sprite_array(tile_sprs, map_x, map_y, citymode,
>                                      &solid_bg, &pplayer);
>     int i = 0;
> 
>     for (i = 0; i < count; i++) {
>       if (tile_sprs[i].sprite) {
>       gui_put_sprite_full(pcanvas_store,
>                           canvas_x + tile_sprs[i].offset_x,
>                           canvas_y + tile_sprs[i].offset_y,
>                           tile_sprs[i].sprite);
>       }
>     }
> 
> since fill_tile_sprite_array is also not a cheap function. So it would
> be cache
> 
>  (x,y) -> struct *sprite
> 
> which is limited in size and have LRU (or some other) semantics. An
> entry in the cache will be invalidated (read removed) if something the
> this position changed.

I have implemented this preliminary. I get a speedup of factor 3 for
put_one_tile for the xaw client.

Measuring the same function in the FS client turned out to be a big
suprise: 55us vs 3us. The FS client is over factor 15 slower. This was
suprising since the code of the xaw client and the FS client for the
function gui_put_sprite_full is very similar. I was able to decrease
the amount to 30us by recycling the GC. Still a factor of 10 for the
same code. After a lot of searching and trying it turned out that if I
disable transparency support in the FS client the number drops to 3us.

However there is no transparency stuff in gui_put_sprite_full. So I
guess it is caused by the way transparency is achieved: Pixmaps are
off-screen drawing areas stored in the server. XImages are read/write
areas stored at the client. You can convert between these two. Drawing
primitives like text and lines are available only to Pixmaps. However
you can read pixel values from XImages which isn't the case for
Pixmaps. So how is transparency implemented? The client fetches a
Pixmap from the server and converts it to a XImage. This is done two
times for the source and destination. Then client then does the alpha
blending (this is also performance intensive but optimized quite
good). After this it sends the XImage back to the server as an
Pixmap. Summary: a lot of data is transferred. The dumps I made on the
X11 traffic confirm this: 3mb for the xaw client and 16mb for the FS
client.

So it looks like this amount of traffic kills the server and it can't
send/receive/respond fast to "normal" operations like done in
gui_put_sprite_full.

So I searched for an alternative way to get the performance. The
XRender extension seems like a good candidate. It is server only AFAI
tell. But there no f***ing docu on the net except a short presentation
and undocumented header files. I have managed to produce a short
example program for testing. It looks like it works. The next step is
to implement in the FS client and measure its speed.

If this doesn't work I think we have to switch (read provide an extra
backend) to OpenGL.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Some development methodoligies suck. In fack, I think most of them
   do. The Linux kernel development is an unorganized mess. The
   OpenBSD kernel development is a closed mess. XFree86 development
   is a mysterious mess. And that's before we even get to proprietary
   software, which is often ten times worse"
    -- John Goerzen in freeciv-dev