I originally wrote this message 4 days ago, and the list moderator has still not approved it for submission (it was held because the attachments exceed 40 KB). So, I have placed the attachments on a web server and re-sent the messages without them.
The attachments are available at: http://israel.logiclrd.cx/patch/ I'll take them down once the message with attachments hits the list. Jonathan Gilbert ----------------- Original message: ----------------- At 02:12 AM 05/03/2005 -0500, I wrote: >Please find attached the following files: > >* libgdiplus.diff (patch -p0 in ./libgdiplus) >* System.Drawing.diff (patch -p0 in ./mcs/class/System.Drawing) >* lockbits.tgz (tar zvfx in ./) Updated diffs and some extra testing code: testgif.tgz (DOES NOT contain a subdirectory; untar directly within the intended destination) Changes from the previous patch: * Fixed the call to gdip_is_an_indexed_pixelformat that did not actually call the function because it was missing the argument list. * Added indexed loading & saving support to gifcodec.c. * Updated Image.Palette to behave like Microsoft's implementation. I discovered its bizarre behaviour when I tried to write a program for the Microsoft framework to save an indexed 8-bit Bitmap with a custom palette. It does not actually behave like a property, and should really have been engineered as two separate functions, since there is no persistence involved. Reading from the property creates a new instance of System.Drawing.Imaging.ColorPalette and fills it from the underlying GDI+ GpImage object. However, the underlying GpImage's palette is only updated if you assign to the property. Since you are not allowed to create instances of ColorPalette directly, you end up having to write code like this: ColorPalette palette = my_bitmap.Palette; for (int i=0; i < palette.Entries.Length; i++) palette.Entries[i] = Color.FromArgb(ar, gu, ments); my_bitmap.Palette = palette; /* assign the same instance back! if this is skipped, the image file will display and save with the old palette */ This is not documented in MSDN! But whatever the case, mono now behaves the same way. Oh, and one other thing: This time I actually verified that the diffs apply cleanly :-) Jonathan Gilbert _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
