> Still, 16-bit should give you a 5-6-5 mode in practice (or maybe 5-5-5), > which is near enough true colour... Where I have seen problems it's > generally been with indexed palettes, so you 16-bit colour shouldn't be > an issue. Maybe it just gets confused if it thinks it can do 8-8-8 but > the driver thinks it is 5-6-5 or something? >
I'm relatively certain that microwindows is using 5-6-5 mode, as that's how the hardware is configured. I think this issue has something to do with how the bits are being packed for final display. I see very strange behavior when changing the color values in the white range above 0xF9F9F9. For example, if I have an image with a white value of 0xFFF7FF it will accurately reproduce the color. If I change that value to 0xF7FFFF it will produce a pattern on the screen that seems to have some pixels turned on and others turned off. To expand on the "striped" pixel situation, the following represents a portion of the display with "X" representing a pixel turned on displaying the proper color: XX X XX X XXX XX X XX X XXX XX X XX X XXX XX X XX X XXX this grid would represent a 13x4 section of screen. This is not an exact recreation of what is produced, but patterns similar to this appear. Which leads me to believe that some pixel color data is being masked or bit shifted or something. Anyways, as I said yesterday, I'm diving into Fl_Image.cxx and related files searching for how fltk is handling images. If anyone has suggestions as to which file(s) might be helpful in this search I would love to hear them as always. thanks, Mike McCune Navigation Solutions 248 282 5407 _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
