Okay, well, kangaroo sent me a screenshot of the erroneous display in the FileDialog, and turns out it was not an issue of red & blue channels being swapped by not paying attention to endianness. It *was* an endianness issue, but the effect was not what had been mentioned :-) What was actually happening was that the blue channel was being forced to 0xFF.
This screenshot shows a section of kangaroo's screenshot on the left, followed by Windows' own display, and then on the right, the top half shows what the R, G, B channels are in kangaroo's screenshot, and the bottom half shows what the R, G, B channels *should* be. Note that transparency was still being taken into account, but wherever the pixel was opaque, the blue channel was on solid! I tracked this down to the code that prepares Bitmap data with a non-alpha PixelFormat for display with Cairo, which always pays attention to the alpha channel. It was doing something along these lines: int force_alpha = 0xFF000000; for (each pixel) pixel |= force_alpha; I have changed the force_alpha assignment to a set_pixel_bgra, which should fix the problem. I have no way to test whether it does in fact solve this issue; the output looks exactly the same (it was correct before) on my little-endian system. I invite anyone with a big-endian system to apply the latest version of the patch: http://israel.logiclrd.cx/patch/ ..and try out the winforms/filedialog test case :-) Are there any other issues with my patch? Jonathan Gilbert _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
