XWin 4.3.0-50 crashes with -multiwindow (ping Earle)

[Earle F. Philhower III]

Howdy Harold,

At 12:00 AM 3/26/2004 -0500, Harold wrote:
>Nope, not going to beat you to it.  This issue is what I was referring to 
>when I said that Earle should probably look at the PixmapBytePad patch to 
>make sure it was complete.  :)

There's a saying I've learned from my verification engineers:  If you don't 
test it, it won't work!

WinXP doesn't list 24bpp mode anymore, VICE doesn't compile under cygwin 
w/o work, and I'm not likely to shell out $$M to buy an Oracle DB. :)  To 
top it off, freedesktop's CVS /tmp disk is out of space so CVS isn't 
working.  Ouch!

I did some unit-testing of the undocumented BitsPerPixel() macro, and it 
seems to be what's needed.  Changing line 74 to
 >  effXBPP = BitsPerPixel(pixmap->drawable.depth);
will set it to 32 when given a 24-bpp drawable, giving a pixel stride of 4 
bytes as desired.  It also doesn't break any of the 1-, 16-, or 32-bit 
icons that I was able to test (the return values of BPP() match expected 
there too), but I still have no 24-bpp icons to try.

I'll try the commit again tomorrow morning, but if Fabrizio wants to beat 
up his local copy before then and report back it'd be appreciated!

>Also, I think you mentioned that 1 bit pixmaps were messed up.  If that is 
>still the case, it is because the GDI DIB 1 bit bitmap has a reversed byte 
>order.  So, you'll have to swap the byte order for 1 bit pixmaps when you 
>convert them.  Give that a try and let me know if it works... ping me as 
>soon as you look into it cause I'm really wondering if that will fix it.

This was way back when I was first writing it, IIRC.  I don't think I've 
seen any 1-bit icon problems or heard of any (except for the complaint that 
xcalc's scaled icon was ugly) since.  If someone has a specific problem 
I'll look into it, but 1-bit is working 100% AFAIK...

-Earle F. Philhower, III
  earle@ziplabel.com
  cdrlabel - ZipLabel - FlpLabel
  http://www.cdrlabel.com