Re: DIB engine

Well, when I look at the bug report, I see this : '* the X bitmap has to be in the format of the X display. So if X is running in 15bpp, a 32bpp DIB is converted to 15bpp, the operation is performed in 15bpp, and the bitmap is then converted back to 32bpp. Obviously this implies that each operation occurs a loss of color resolution (fortunately they should not accumulate).' This is, AFAIK, not a problem anymore on XFree 4 (at least on the drivers based on the 'fb' driver) as they support all Pixmap depth whatever the depth of the current screen. For example, on my 16bpp display, 'xdpyinfo' gives me this : number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 So it should support almost all 'usual' formats (except the funky non 555 / 565 formats or BGR ones that are pretty rare). As far as I can remember, my Solaris box at work does also support a lot of Pixmap formats even on a 32bpp screen. There may be problems with the palette for the 'depth 8' format though. But, as far as I can remember, the other big problem comes from the 'exception handler' that is needed to detect direct write from the Windows program to the DIB (or maybe I am thinking about something completely else :-) ) to be sure that the X pixmap and the Windows DIB are always in sync one with the other. And that cannot be solved easily with X Pixmaps at all (maybe hacking around with XShmPixmaps). Anyway, enough of my ramblings for tonight :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/