Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 37608 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 14551 [details]
Screenshot of the bug in Ubuntu
I'm the developer of SharpFont and a user came to me with an issue that only existed when running my example program on Linux with Mono. That issue is available here:
Essentially, on Linux, neither of us were seeing the same bitmap transparency that we did on Windows with GDI+.
I did a little more digging and found that gdip_convert_indexed_to_rgb sets all the alpha values to 0xFF if the bitmap's ColorPalette didn't have the PaletteFlagsHasAlpha flag set in this bit of code:
So the solution was to set the flag manually with reflection as so:
> typeof(ColorPalette).GetField ("flags", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic).SetValue (palette, palette.Flags | 1);
And this temporarily fixed the issue. Taking a peek at the same code on Windows/GDI+, the Bitmap gives you a ColorPalette of 0x04 (PaletteFlagsHalftone) and this seems to be enough to convert with transparency. Note that this is all on a Bitmap created with PixelFormat.8bppIndexed.
Since I can only attach a single file, I chose a screenshot of the bug in Ubuntu. This bug should be reproducible by cloning SharpFont and running the example program, but please let me know if you need anything else to reproduce the bug or clarify anything.
Created attachment 15847 [details]
Screen shot of the example under wine (top) and native linux (bottom)
Top is is wine + dotnet2 + MS libgdiplus (wine's gdiplus does not work correctly with wine + dotnet2), bottom is linux mono 188.8.131.52 and libgdiplus 3.12 .
This is the same as http://htl10.users.sourceforge.net/tmp/Screenshot%20from%202016-04-26%2015-24-52.png mentioned in
just in case I want to clean /tmp/ at some point.
The lines concerned came from this change:
Author: Peter Dennis Bartok <email@example.com>
Date: Mon Jun 13 19:17:10 2005 +0000
* bitmap.c, image.c, gdip.h, bmpcodec.c, jpegcodec.c, tiffcodec.c,
gifcodec.c, gifcodec.h, pngcodec.c, pngcodec.h: Re-applied two
previous changes, since #75254 is now fixed
2005-06-13 Peter Bartok <firstname.lastname@example.org>
svn path=/trunk/libgdiplus/; revision=45904
There are various comment in it saying cairo wants all the alpha values to 0xFF .
This seems to be related, and rather surprised that after 10 years, still around:
libgdiplus's 'make check' runs only 3 tests; it might be interesting to adapt some of wine's unit tests for their gdiplus implementation. Their tests look larger.