[Mono-winforms-list] Jonathan Gilbert's indexed colorsupport patch

[Peter Dennis Bartok]

Jonathan,

The images used by the file dialog are PNGs, not BMPs.

Peter

-----Original Message-----
From: "Jonathan Gilbert" <2a5gjx302 at sneakemail.com>
To: <mono-winforms-list at lists.ximian.com>
Date: Friday, 27 May, 2005 22:21
Subject: Re: [Mono-winforms-list] Jonathan Gilbert's indexed colorsupport 
patch


>At 05:50 PM 26/05/2005 -0600, Peter Dennis Bartok wrote:
>[snip]
>>It seems to handle images loaded from disk with no problem on both little
>>and big endian systems (as shown by winforms/endian), but when images are
>>retrieved from resources (resx), colors are swapped. The 
>>winforms/filedialog
>>test app shows the problem very nicely.
>
>There seems to be something really odd going on here. You assert that
>winforms/endian works perfectly (the only deviation from straight lines of
>colour being the 1-bit black & white images) on big-endian systems such as
>OS X? And yet, winforms/filedialog does not work properly?
>
>By the way, I notice that winforms/filedialog does not have correct
>transparency for the buttons on the left of the dialog, but I don't know if
>that's a bug in the code or in the images being embedded. That's an
>unrelated issue though :-)
>
>I have investigated the code paths used by the two ways of loading a
>bitmap. They proceed as follows:
>
>Image.cs:                                 Image.cs:
>Image.FromFile(...)                       Image.FromStream(...)
>       |                                          |
>       v                                          v
>gdipFunctions.cs:                         gdipFunctions.cs:
>GDIPlus.GdipLoadImageFromDelegate_linux   GDIPlus.GdipLoadImageFromFile
>       |                                          |
>(managed <-> unmanaged boundary; below here is inside libgdiplus)
>       |                                          |
>       v                                          v
>image.c:                                  image.c:
>GdipLoadImageFromDelegate_linux           GdipLoadImageFromFile
>       |                                          |
>       v                                          v
>bmpcodec.c:                               bmpcodec.c:
>gdip_load_bmp_image_from_stream_delegate  gdip_load_bmp_image_from_file
>           \                                  /
>            \                                /
>             \                              /
>             _\|                          |/_
>           bmpcodec.c:
>           gdip_read_bmp_image_from_file_stream
>
>In other words, the two functions converge onto the same underlying code.
>Apart from the mechanics of reading bytes from the files, streams and files
>are read in exactly the same way. Therefore I don't see how one can work
>and the other not!
>
>Anyway, I will look very closely at how bmpcodec.c reads in the palette
>data and let you know if I find any glaring errors.
>
>The closest thing I have to a big-endian system at the moment is PearPC
>running OS X, and it is somehow incompatible with the mono JIT's exception
>handling mechanism =/ If I do come up with a revision, what do you propose
>for testing it? I have yet to actually abserve the endian incompatibility
>myself.
>
>Jonathan Gilbert
>
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>