Re: [Bug-XBoard] [bug #27630] Black fairy pieces partly transparent

[h.g. muller]

> Maybe we should consider providing a way at compile time to choose which 
> way it's built?  I think including an additional directory for the bitmap 
> differences shouldn't cause much size increase to the source tarball.  Or 
> maybe it would-- how do we get lzma's soliid archive feature into the 
> tarball?  Anyway, something to think about.

The XBoard pixmaps are in fact totally ridiculous. Each pixmap comes in two 
practically identical copies. That is, the picture is exactly the same, but 
it just assigns a different color to the . character (which indicats the 
backgrund in all cases). This could have been trivially done at run time. 
In fact the same character strings describing the four colors now occur in 
every pixmap. Perhaps the compiler is smart enough to collapse all those 
copies of the same string to one in initialized read-only data, but perhaps 
it is not.

It would be much more efficient to initialize the color indications with 
NULL in all the pixmap source files, and put the pointer to the actual 
strings there only before converting them to internal format (i.e before 
feeding them to XpmCreatePixmapFromData). That would make the dl & ll 
pixmaps truly identical to the dd and ld pixmaps, reducing the number of 
pixmaps by 2. If this system is used, the black pixmaps can be included as 
3-color pixmaps, using a different character for the square color and the 
details, but under control of a transparancy option, the color for the 
details could be set to the square color in stead of the white-piece color.