> FLTK-Version: 1.1.9 > > I have the following problem: I have a png-image which forms the > background. Then I have a second png-image which is > postitioned on the > background-png. The second png has also an area where it is > transparent.
Probably not relevant, but there used to be a bug in the fltk configure script where it would fail to detect that the PNG lib supported transparency. Not sure when that was fixed, but I think it was fixed before 1.1.9. In any case, look in your generated config.h file and ensure that it contains lines like this: /* * Do we have the png_xyz() functions? */ #define HAVE_PNG_GET_VALID 1 #define HAVE_PNG_SET_TRNS_TO_ALPHA 1 If it does not, or has lines like: #undef HAVE_PNG_GET_VALID #undef HAVE_PNG_SET_TRNS_TO_ALPHA Then hand-edit the config.h and rebuild your fltk lib, see if that helps (though I suspect it may not make much difference based on the symptoms you describe.) > Now at the place where the second image is transparent, the > background > image has its color changed. The color should be white, but is now > yellow, where the transparency of the second pnd is... That does sound odd. Do you know what the RGBA values in your transparent region actually are? I suppose an "ideal" transparent region might be 0,0,0,0, so it is hard to see how that would be yellow, regardless of any endian issues that might exist. I suppose a transparent region might by 255,255,255,0 (RGBA order) as I think win32 prefers that... If your endianness is reversed (ABGR), that might give an opaque cyan region - but hard to see why it would be yellow (I guess that would have to be ARGB.) Also, how "yellow" is the yellow region? Can you grab some of the pixels from the display and find out what the resulting RGBA values on screen are? Might help to pin down where the error is coming from. > Now I have to mention a second thing: I had to deal in the past with > some little- /big-endian problems. I had to exchange the functions > "bgrx_converter" and "xrgb_converter" and also the functions > "xrrr_converter" and "rrrx_converter" (in fl_draw_image.cxx) so that > images where shown correctly. Hmm, I've built fltk and png for a variety of platforms and have never had to do that, both fltk and libpng seem to understand endian issues OK. Again, might be worth checking your config.h has detected your target endian properly, look for: /* * WORDS_BIGENDIAN: * * Byte order of your machine: 1 = big-endian, 0 = little-endian. */ #define WORDS_BIGENDIAN 0 (that's from an x86 machine) #define WORDS_BIGENDIAN 1 (that's from a PPC mac) Might be worth checking your libpng has detected the correct endian too... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
