Still wrong same problem.
-kangaroo
On 2-Jun-05, at 7:57 PM, Jonathan Gilbert wrote:
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
!DSPAM:429f9c8a242202012714467!
_______________________________________________
Mono-winforms-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
