On Wed, 24 Oct 2001, Mark Vojkovich wrote: > On Wed, 24 Oct 2001, Dr Andrew C Aitchison wrote: > > While I don't know of any plans, and I agree that the app is indeed the > > problem, I think the hack to implement PseudoColor on DirectColor should > > not be too hard - at depth 24 the two visuals are just different ways of > > interpreting the colormap. > > You have to do it with shadow buffers for every depth 8 window. > Whenever you change the palette you have to redraw (retranslate) the > 8 bit data. You won't pass the test suite if you can't read back > the 8 bit data you've just written. In theory you could have any > number of PseudoColor maps though.
Can't you just put the 8 bits into each of the red, green and blue bytes in the DirectColor framebuffer ? Then the hardware palette will think it is doing 3 8bit->8bit lookups, but logically it will be doing 1 8bit->24bit lookup. Having to read the data back makes it tempting to use depth=8, bits_per_pixel=32 pixmaps. This will give you not only the fast colormap updates which apps which have a reason for pseudocolor need, but also the colormap flashing which dumb p.c. apps force on use. Generally an accurate implementation of pseudocolor. The cards that support 8+24 could get rid of colormap flashing on the (default?) TrueColor visual, if we don't mind losing gamma correction on TrueColor (The RAMdacs I've seen allow you use the "spare" byte to indicate Direct or True color for each pixel). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
