[Freeciv-Dev] Re: (PR#2941) RFC: canvas_put_sprite

["esr@xxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>]

Jason Short via RT <rt@xxxxxxxxxxxxxx>:
> put_sprite() will not be the only function.  5-10 other low-level ones 
> will be needed, including put_sprite_fogged.
> 
> The drawback of this is that it doesn't let GUIs do optimizations like 
> (I think) gui-sdl does with fogged ocean tiles.  The advantage is that 
> changes to the drawing code become much easier.  Just look at how easy 
> it is now to make changes to the drawing code in tilespec.c - much 
> easier than for the stuff that is still in gui-xxx/mapview.

Let's step back a moment and look at the systems engineering.

Freeciv is not a real-time game, updates are relatively sparse in both
time and space.  Latency due to network turnaround will often dominate
draw time by an order of magnitude.  We have the luxury of engineering
for long-term maintainability rather than having to scqueeze every
cycle out of the hardware; I say we should use that.

Under these conditions, unifying the drawing code down as far as
BitBlt level would make sense (no that anyone's proposing going that
far).  The fancy optimizations you can get with toolkits like SDL
simply won't gain us any performance in real-world cases, so there is
no loss in keeping the code simple and well-factored.

I didn't have an opinion about this three days ago, but I've read all the
client code since in order to do the mods I needed to crop_sprite().  I
don't know what other people are thinking, but I sense a natural 
plane of cleavage at about the level of pixmap_put_overlay_tile() in
the gdk client.

In this model, the basic primitive of the gui-independent code would
look like "draw this stack of sprites at (x, y)".  The client's job would
basically be to translate that into BitBlts with clipping.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>