[crossfire] Partial transparency

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
> 
>>  IIRC, gtk has no convenient way on handling the alpha channel (the 
>> inconvenient way would be for the program to figure it all on its own, figuring 
>> out the appropriate RGB values, and then drawing those point by point to the 
>> screen.  This is also pretty CPU intensive).  So I don't expect to add that 
>> support anytime soon (it would basically be a complete re-write of how images 
>> are handled).
>>
> Actually, gtk does support it through this api:
> http://www.gtk.org/api/2.6/gdk/gdk-Drawing-Primitives.html#gdk-draw-pixbuf
> However it isn't necessarily fast, but I believe on modern machines, 
> given how little crossfire redraws compared to most things, this cost 
> would not be that significant.

  Not sure of that.  On my old system (dual athlon mp 2000), for it to redraw 
the entire 25x25 map each tick, it really taxes the machine.  Right now, for the 
gtk1 client, it only redraws what changes so isn't as much an issue.  I can't 
remember what I did for the gtkv2 client (I thought I just grabbed the gtkv1 
logic, but too lazy to look).

  But poking in the gtk source code, it does appear it is relatively clever in 
its drawing logic, using shared memory and xrender extension, so performance may 
actually not be that bad.  It'd perhaps be interesting to convert the gtk draw 
code to use the gdkpixbufs instead of the gdkpixmaps and see how much a 
performance difference there is just for standard images, and then start 
throwing in some transparent images.

  This actually is somewhat relevant, because with my proposed lighting redo, 
only draw mechanisms that actually have some form of alpha or lighting logic 
will be able to use it.  So for the current gtk logic, can't really do too much 
given what is there.