This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
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