Poupou's blog
19 news. Page : 1 2
Gendarme Performance Update 
So Mono 2.0 RC1 was tagged this week and, like I did before, I ran my benchmark on Gendarme (results on preview #1, preview #2). No big surprise this time. Since the performance difference is less than 0.5% wrt preview #2 it didn't seem wise to disturb some many electrons for an updated table. So let's create a new one to answer "But just how much time does it take ?". We already know how much time it takes for Mono, but a lot of people work on smaller projects (or subset of large projects). This new table shows how much time Gendarme needs to analyze (using all rules, including smells) some Mono-based OSS projects that I have installed, from repositories*, on my openSUSE11 laptop. Projectsassemblies (#)Time (seconds) banshee (1.2)146.50963 beagle2010.84114 f-spot21743.364386** giver11.137288 gnome-do31.500372 monodoc121.909368 monsoon46.459559 tasque21.898578 tomboy43.549324 So next time you have a few seconds give Gendarme a try on your own projects ;-) * caveat: no debugging symbols - either because most projects dont ship them, or because mono 2.0 MDB format is newer (and incompatible) with the one shipped in openSUSE 11 (mono 1.9.1). ** including 734 seconds inside the quite big Tao.OpenGl.dll. Since I don't suppose f-spot developer's make many changes inside it, I guess it could be removed from the analysis. Poupou's blog, 2008-09-22 03:28:33
So Mono 2.0 RC1 was tagged this week and, like I did before, I ran my benchmark on Gendarme (results on preview #1, preview #2). No big surprise this time. Since the performance difference is less than 0.5% wrt preview #2 it didn't seem wise to disturb some many electrons for an updated table. So let's create a new one to answer "But just how much time does it take ?". We already know how much time it takes for Mono, but a lot of people work on smaller projects (or subset of large projects). This new table shows how much time Gendarme needs to analyze (using all rules, including smells) some Mono-based OSS projects that I have installed, from repositories*, on my openSUSE11 laptop. Projectsassemblies (#)Time (seconds) banshee (1.2)146.50963 beagle2010.84114 f-spot21743.364386** giver11.137288 gnome-do31.500372 monodoc121.909368 monsoon46.459559 tasque21.898578 tomboy43.549324 So next time you have a few seconds give Gendarme a try on your own projects ;-) * caveat: no debugging symbols - either because most projects dont ship them, or because mono 2.0 MDB format is newer (and incompatible) with the one shipped in openSUSE 11 (mono 1.9.1). ** including 734 seconds inside the quite big Tao.OpenGl.dll. Since I don't suppose f-spot developer's make many changes inside it, I guess it could be removed from the analysis. Poupou's blog, 2008-09-22 03:28:33
Hack Week 3 - Gendarme Recap
Last week was the third edition of Novell's Hack Week. During the week I used Ohloh to describe all the changes I made to Gendarme, almost in real-time. Still a quick recap can be easier to read... Framework Enhancements New Severity.Audit for rules that will always trigger but are still useful from time to time (see new rules); New IRule and IRunner TearDown methods were added to allow late reporting (of defects) and any specific rule clean up; New filtering options for defects (see runners) to get shorter, more accurate, reports; New [FxCopCompatibility] attribute to help map between Gendarme and FxCop rules. This will allow us to support the .NET framework [SuppressMessage] attribute. New "engines" support. Engines are building additional data, on top of what Cecil provides, for the rules to consume. The runners ensure of the engine data availability before any rules that requires them start their analysis (i.e. the Check* methods). This part is not yet committed (but should be soon) and will be a moving target until 2.2 is released. Expect a few blog entries on them (there are two engines right now) later this month. Runners Enhancements The console runner has been updated to expose the new framework features, like: --limit=N can be used to limit the number of defects reported during analysis; --severity=... can be used to filter only some severity level (e.g. ignoring audits); --confidence=... can be used to filter results more likely to be false positives. A new step has been added to the wizard runner to set some options before the analysis. Limit the number of defects reported; Set a minimum severity level on defects; Set a minimum confidence level on defects; Select visibility, which allow rules to work only on visible, non-visible or all your code. Rules Quite a lot of moving, renaming and a few optimizations. Expect a bit more of this before 2.2 gets released. New assemblies were created for Code Access Security rules (Gendarme.Rules.Security.Cas) and for generic related rules (Gendarme.Rules.Design.Generic). New ReviewSuppressUnmanagedCodeSecurityUsageRule to show the new Audit severity. This is a good example about something that can't be fixed (for once and for all) but where it's useful, from time to time, to know where they hide. New UseGenericEventHandlerRule to promote the use of EventHandler<TEventArgs> over the creation of delegates. Except for some rules fixes and optimizations that were backported (to 2.0) all this new stuff will be released with Gendarme 2.2 (i.e. with Mono 2.2, not 2.0). More news soon!Poupou's blog, 2008-09-22 03:28:33
Last week was the third edition of Novell's Hack Week. During the week I used Ohloh to describe all the changes I made to Gendarme, almost in real-time. Still a quick recap can be easier to read... Framework Enhancements New Severity.Audit for rules that will always trigger but are still useful from time to time (see new rules); New IRule and IRunner TearDown methods were added to allow late reporting (of defects) and any specific rule clean up; New filtering options for defects (see runners) to get shorter, more accurate, reports; New [FxCopCompatibility] attribute to help map between Gendarme and FxCop rules. This will allow us to support the .NET framework [SuppressMessage] attribute. New "engines" support. Engines are building additional data, on top of what Cecil provides, for the rules to consume. The runners ensure of the engine data availability before any rules that requires them start their analysis (i.e. the Check* methods). This part is not yet committed (but should be soon) and will be a moving target until 2.2 is released. Expect a few blog entries on them (there are two engines right now) later this month. Runners Enhancements The console runner has been updated to expose the new framework features, like: --limit=N can be used to limit the number of defects reported during analysis; --severity=... can be used to filter only some severity level (e.g. ignoring audits); --confidence=... can be used to filter results more likely to be false positives. A new step has been added to the wizard runner to set some options before the analysis. Limit the number of defects reported; Set a minimum severity level on defects; Set a minimum confidence level on defects; Select visibility, which allow rules to work only on visible, non-visible or all your code. Rules Quite a lot of moving, renaming and a few optimizations. Expect a bit more of this before 2.2 gets released. New assemblies were created for Code Access Security rules (Gendarme.Rules.Security.Cas) and for generic related rules (Gendarme.Rules.Design.Generic). New ReviewSuppressUnmanagedCodeSecurityUsageRule to show the new Audit severity. This is a good example about something that can't be fixed (for once and for all) but where it's useful, from time to time, to know where they hide. New UseGenericEventHandlerRule to promote the use of EventHandler<TEventArgs> over the creation of delegates. Except for some rules fixes and optimizations that were backported (to 2.0) all this new stuff will be released with Gendarme 2.2 (i.e. with Mono 2.2, not 2.0). More news soon!Poupou's blog, 2008-09-22 03:28:33
Big Bump
Earlier this week the Mono 2.0 branch was tagged for preview #2. Included with it, inside mono-tools, is the updated Gendarme. Most of the changes between now and the first preview are not very visible. Like promised a lots of rules were tweaked to reduce false positives. Some of them were also optimized to be (quite a bit) faster. A big thanks to everyone for the feedback (and the patches too ;-). Hopefully I'll have time to get more fixes into the branch before the release candidate in early September. So what's the most visible change ? Well from now on Gendarme version will match Mono version numbers. This should avoid any confusion (e.g. bug reports) concerning the versions and it also answers the feedback I received that 0.2 was not very representative of Gendarme's status. This second preview is also a good time to update the performance table of my previous blog entry. Again I compared the time needed for Gendarme 0.0.5.1, shipped with Mono 1.9.1 (confusing heh?), versus the 2.0p2 release (less confusing :-) by executing each rule category (and default one) on all (72) Mono 2.0 assemblies. Gendarme 0.0.5.1Gendarme 2.0 p2ChangeMean time perrule delta # rulestime# rulestimerules factortime factor BadPractice 7 9.839234 13 20.940601 186% 212.83% 0.21 Concurrency 3 10.03967 6 14.167014 200% 141.11% -0.99 Correctness 7 11.229753 13 15.350205 186% 136.69% -0.42 Design 25 4.437044 33 3.738977 132% 84.27% -0.06 Exceptions 2 9.743716 7 16.194831 350% 166.21% -2.56 Interoperability4 9.044328 5 14.150847 125% 156.46% 0.57 Maintainability 0 0 6 17.895726 N/A N/A N/A Naming 11 8.482943 12 2.145394 109% 25.29% -0.59 Performance 13 155.027838 25 33.18588 192% 21.41% -10.60 Portability 4 11.598787 5 21.198526 125% 182.77% 1.34 Security 10 6.734685 10 8.593943 100% 127.61% 0.19 Serialization 0 0 7 1.349845 N/A N/A N/A Smells 6 652.531303 6 686.105971 100% 105.15% 5.60 UI 3 3.272789 3 0.114405 100% 3.50% -1.05 TOTAL 95 891.98209 151 855.132165 159% 95.87% -3.73 default 89 174.698965 145 67.466905 163% 38.62% -1.50 So the new total percentage of 95.87% is a bit better than the previous one (99.15%). Not surprising since the smells are taking a huge amount of time, compared to all other rules, and have not been much optimized since the first preview (but I got ideas for them too ;-). However there's a bigger difference for the default rule set (what the console runner execute unless instructed otherwise). It nows takes 38.62% of the time (versus 57.54% for the first preview). In both cases the times are compared to the version 0.0.5.1 and includes the 56 additional rules. The win32 installer for Gendarme 2.0p2 will be available shortly on the google group file section. Linux packages (i.e. mono-tools) should be available early next week.Poupou's blog, 2008-09-22 03:28:33
Earlier this week the Mono 2.0 branch was tagged for preview #2. Included with it, inside mono-tools, is the updated Gendarme. Most of the changes between now and the first preview are not very visible. Like promised a lots of rules were tweaked to reduce false positives. Some of them were also optimized to be (quite a bit) faster. A big thanks to everyone for the feedback (and the patches too ;-). Hopefully I'll have time to get more fixes into the branch before the release candidate in early September. So what's the most visible change ? Well from now on Gendarme version will match Mono version numbers. This should avoid any confusion (e.g. bug reports) concerning the versions and it also answers the feedback I received that 0.2 was not very representative of Gendarme's status. This second preview is also a good time to update the performance table of my previous blog entry. Again I compared the time needed for Gendarme 0.0.5.1, shipped with Mono 1.9.1 (confusing heh?), versus the 2.0p2 release (less confusing :-) by executing each rule category (and default one) on all (72) Mono 2.0 assemblies. Gendarme 0.0.5.1Gendarme 2.0 p2ChangeMean time perrule delta # rulestime# rulestimerules factortime factor BadPractice 7 9.839234 13 20.940601 186% 212.83% 0.21 Concurrency 3 10.03967 6 14.167014 200% 141.11% -0.99 Correctness 7 11.229753 13 15.350205 186% 136.69% -0.42 Design 25 4.437044 33 3.738977 132% 84.27% -0.06 Exceptions 2 9.743716 7 16.194831 350% 166.21% -2.56 Interoperability4 9.044328 5 14.150847 125% 156.46% 0.57 Maintainability 0 0 6 17.895726 N/A N/A N/A Naming 11 8.482943 12 2.145394 109% 25.29% -0.59 Performance 13 155.027838 25 33.18588 192% 21.41% -10.60 Portability 4 11.598787 5 21.198526 125% 182.77% 1.34 Security 10 6.734685 10 8.593943 100% 127.61% 0.19 Serialization 0 0 7 1.349845 N/A N/A N/A Smells 6 652.531303 6 686.105971 100% 105.15% 5.60 UI 3 3.272789 3 0.114405 100% 3.50% -1.05 TOTAL 95 891.98209 151 855.132165 159% 95.87% -3.73 default 89 174.698965 145 67.466905 163% 38.62% -1.50 So the new total percentage of 95.87% is a bit better than the previous one (99.15%). Not surprising since the smells are taking a huge amount of time, compared to all other rules, and have not been much optimized since the first preview (but I got ideas for them too ;-). However there's a bigger difference for the default rule set (what the console runner execute unless instructed otherwise). It nows takes 38.62% of the time (versus 57.54% for the first preview). In both cases the times are compared to the version 0.0.5.1 and includes the 56 additional rules. The win32 installer for Gendarme 2.0p2 will be available shortly on the google group file section. Linux packages (i.e. mono-tools) should be available early next week.Poupou's blog, 2008-09-22 03:28:33
Client Certificate Support Update
Good news! It is now possible, using the Mono 2.0 profile, to use X.509 client certificates with HttpWebRequest. Why such a restriction ? Because the original API was badly designed. It only accept X509Certificate and provided no way to supply the private key associated with the (public key of the) certificate. Then how could this work on MS runtime ? Because certificates could be part of a certificate store (even if the store weren't exposed before fx 2.0). In this case CryptoAPI could have a link between the certificate store and the key store (if both were available simultaneously when imported). But it could fail too ;-) What changed in 2.0 ? A new, more complete, class X509Certificate2 is available. This new class supports loading formats that includes private keys, e.g. PKCS#12 files - which means the private key, if available, can be used for the signing operation required by client certificates in SSL/TLS. Also the class inherits from the older X509Certificate, making it usable for HttpWebRequest. So everything is fine now ? No, this still works only for 2.0 if you load a certificate with a private key. I.e. it won't work if you depend on CryptoAPI magic associations. Still this allows some new scenarios to work, including (but not tested) accessing web services with client certificates. The wiki page, UsingClientCertificatesWithXSP, has been updated with sample code. Have fun!Poupou's blog, 2007-05-14 03:33:20
Good news! It is now possible, using the Mono 2.0 profile, to use X.509 client certificates with HttpWebRequest. Why such a restriction ? Because the original API was badly designed. It only accept X509Certificate and provided no way to supply the private key associated with the (public key of the) certificate. Then how could this work on MS runtime ? Because certificates could be part of a certificate store (even if the store weren't exposed before fx 2.0). In this case CryptoAPI could have a link between the certificate store and the key store (if both were available simultaneously when imported). But it could fail too ;-) What changed in 2.0 ? A new, more complete, class X509Certificate2 is available. This new class supports loading formats that includes private keys, e.g. PKCS#12 files - which means the private key, if available, can be used for the signing operation required by client certificates in SSL/TLS. Also the class inherits from the older X509Certificate, making it usable for HttpWebRequest. So everything is fine now ? No, this still works only for 2.0 if you load a certificate with a private key. I.e. it won't work if you depend on CryptoAPI magic associations. Still this allows some new scenarios to work, including (but not tested) accessing web services with client certificates. The wiki page, UsingClientCertificatesWithXSP, has been updated with sample code. Have fun!Poupou's blog, 2007-05-14 03:33:20
Silverlight Security Model
Shawn Farkas has a great introduction to the new Silverlight Security Model. Shawn has long been the best voice to explain all the security stuff built into the newer .NET framework releases. I'm glad he'll continue with Silverlight!Poupou's blog, 2007-05-14 03:33:20
Shawn Farkas has a great introduction to the new Silverlight Security Model. Shawn has long been the best voice to explain all the security stuff built into the newer .NET framework releases. I'm glad he'll continue with Silverlight!Poupou's blog, 2007-05-14 03:33:20
I submit Mr. T
to Jackson's SWF contest. "Blogged to death" picture but still the first EMF worth showing under the category "small is beautiful" ;-) using System; using System.Drawing; using System.Drawing.Imaging; using System.Windows.Forms; public class MainForm : Form { private Metafile metafile; private float ratio; public MainForm (Metafile mf, float r) { metafile = mf; ratio = r; Size = new Size (340, 450); Paint += new PaintEventHandler (PaintMetafile); } void PaintMetafile (object sender, PaintEventArgs e) { e.Graphics.ScaleTransform (ratio, ratio); e.Graphics.DrawImage (metafile, 10, 10, metafile.Width, metafile.Height); } [STAThread] static int Main (string[] args) { if (args.Length == 0) { Console.WriteLine ("mono metaview.exe metafile.[wmf|emf]"); return 1; } Metafile metafile = new Metafile (args [0]); Console.WriteLine ("Width {0}, Height {1}", metafile.Width, metafile.Height); float ratio = (args.Length > 1) ? Single.Parse (args [1]) : (320.0f / metafile.Width); Application.Run (new MainForm (metafile, ratio)); return 0; } } of course this needs the, soon to be commited, libgdiplus update. Poupou's blog, 2007-03-19 04:35:29
to Jackson's SWF contest. "Blogged to death" picture but still the first EMF worth showing under the category "small is beautiful" ;-) using System; using System.Drawing; using System.Drawing.Imaging; using System.Windows.Forms; public class MainForm : Form { private Metafile metafile; private float ratio; public MainForm (Metafile mf, float r) { metafile = mf; ratio = r; Size = new Size (340, 450); Paint += new PaintEventHandler (PaintMetafile); } void PaintMetafile (object sender, PaintEventArgs e) { e.Graphics.ScaleTransform (ratio, ratio); e.Graphics.DrawImage (metafile, 10, 10, metafile.Width, metafile.Height); } [STAThread] static int Main (string[] args) { if (args.Length == 0) { Console.WriteLine ("mono metaview.exe metafile.[wmf|emf]"); return 1; } Metafile metafile = new Metafile (args [0]); Console.WriteLine ("Width {0}, Height {1}", metafile.Width, metafile.Height); float ratio = (args.Length > 1) ? Single.Parse (args [1]) : (320.0f / metafile.Width); Application.Run (new MainForm (metafile, ratio)); return 0; } } of course this needs the, soon to be commited, libgdiplus update. Poupou's blog, 2007-03-19 04:35:29
Feeding the monkeys
Work continues on the WMF parser. Things looks a lot better than last week (good sign). It's surprising what you can get from a few, but well choosen, record types. So far it proves the 80-20 rule. Here are two other samples I got from the old, but downloadable, OpenClipArt.org cliparts. Both are WMF metafiles, like my previous telescope sample. Both are mostly correct, except for the over filled text areas. Note the nice effect on the apple surface. WMF is an old 16bits technology so this is done by drawing multiple lines with different colors. Simple and surprising (at least the first time) as you know there's no code to do that ;-) Seriously I couldn't blog them before I got colors working ;-) Sadly it seems that EMF, EMF+ (using GDI+ functions) and EMF dual (having both) files are harder to find (none are in the OpenClipArt archive). Generating them myself feels like kind of cheating... and not very good test cases. Got some ? please email me! On a totally unrelated news I finally (because not available in Canada) got my N800 thanks to the discount code (not available from Canada) and a friend. More on that soon... Poupou's blog, 2007-03-19 04:35:29
Work continues on the WMF parser. Things looks a lot better than last week (good sign). It's surprising what you can get from a few, but well choosen, record types. So far it proves the 80-20 rule. Here are two other samples I got from the old, but downloadable, OpenClipArt.org cliparts. Both are WMF metafiles, like my previous telescope sample. Both are mostly correct, except for the over filled text areas. Note the nice effect on the apple surface. WMF is an old 16bits technology so this is done by drawing multiple lines with different colors. Simple and surprising (at least the first time) as you know there's no code to do that ;-) Seriously I couldn't blog them before I got colors working ;-) Sadly it seems that EMF, EMF+ (using GDI+ functions) and EMF dual (having both) files are harder to find (none are in the OpenClipArt archive). Generating them myself feels like kind of cheating... and not very good test cases. Got some ? please email me! On a totally unrelated news I finally (because not available in Canada) got my N800 thanks to the discount code (not available from Canada) and a friend. More on that soon... Poupou's blog, 2007-03-19 04:35:29
Metafiles
Today the biggest, API wise, missing feature in libgdiplus are metafiles. Just like the handling of icons, metafile support exists in several ways in GDI+. First we have the System.Drawing.Imaging.Metafile class, which supports both the older (16bits) WMF and the newer (32bits) EMF formats (each one having some subformats to deal with). Unlike the Icon class Metafile inherits from the System.Drawing.Image class, so you can use them pretty much like any Bitmap, including the 30 overloads of Graphics.DrawImage method. Beside being very badly documented, this class design is also kind of surprising. It has nearly different 40 constructors to allow playing or recording a metafile. Add to that (only) seven methods, including five overloads to get the metafile's header MetafileHeader, one to get the HENHMETAFILE handle and one to replay records (not the whole metafile) and you complete the class. Then we have two separate codecs, one for WMF and one for EMF. Both are decoders only, which means they get used for Image.From[File|Stream] but won't help you to save a metafile, e.g. Image.Save. Enough text for now... MS System.Drawing/GDI+ versus Mono/Libgdiplus The Mono's picture was generated using a very limited WMF codec/parser, it doesn't call functions for half of the metafile commands (e.g. in this picture we're visually missing MoveTo and Arc). The next step is to review all existing *Image* code and, in most case, adapted not to use the bitmap data directly (e.g. width). Once this is done, I'll resume work on the WMF parser, then the EMF parser and post pictures from time to time. P.S. I have not looked much to find free WMF and EMF(+) metafile samples but if you have some free ones (this worked so well for the Vista icons, thanks to everyone :-) I'd like them for the test suite. Right now they don't need to be torture tests ;-). Thanks!Poupou's blog, 2007-02-26 04:31:07
Today the biggest, API wise, missing feature in libgdiplus are metafiles. Just like the handling of icons, metafile support exists in several ways in GDI+. First we have the System.Drawing.Imaging.Metafile class, which supports both the older (16bits) WMF and the newer (32bits) EMF formats (each one having some subformats to deal with). Unlike the Icon class Metafile inherits from the System.Drawing.Image class, so you can use them pretty much like any Bitmap, including the 30 overloads of Graphics.DrawImage method. Beside being very badly documented, this class design is also kind of surprising. It has nearly different 40 constructors to allow playing or recording a metafile. Add to that (only) seven methods, including five overloads to get the metafile's header MetafileHeader, one to get the HENHMETAFILE handle and one to replay records (not the whole metafile) and you complete the class. Then we have two separate codecs, one for WMF and one for EMF. Both are decoders only, which means they get used for Image.From[File|Stream] but won't help you to save a metafile, e.g. Image.Save. Enough text for now... MS System.Drawing/GDI+ versus Mono/Libgdiplus The Mono's picture was generated using a very limited WMF codec/parser, it doesn't call functions for half of the metafile commands (e.g. in this picture we're visually missing MoveTo and Arc). The next step is to review all existing *Image* code and, in most case, adapted not to use the bitmap data directly (e.g. width). Once this is done, I'll resume work on the WMF parser, then the EMF parser and post pictures from time to time. P.S. I have not looked much to find free WMF and EMF(+) metafile samples but if you have some free ones (this worked so well for the Vista icons, thanks to everyone :-) I'd like them for the test suite. Right now they don't need to be torture tests ;-). Thanks!Poupou's blog, 2007-02-26 04:31:07
Codecs - ICO
I was about to blog about metafiles when I realized I didn't talk, well blog, about icons, so let start with them... Icon support exists in two ways in System.Drawing and libgdiplus. First there's the Icon class which, for some unknown (to me) reason, doesn't inherit from the Image class. This part existed, up to recently, in a fully managed implementation. However this implementation wasn't able to coexist with native code when using handles e.g. Bitmap.FromHicon(icon.GetHandle);. The second place where icons could be used, which was totally missing in Mono 1.2.0, is in the ICO codec. This allows the creation of a Bitmap instances from any ICO file. Well almost any ICO as it turns out GDI+ ICO codec is more limited than what GDI (and System.Drawing.Icon) support (e.g. 32bpp icons). So what's new ? The latest (and greatedt) Mono, version 1.2.3, has full support for both icon cases, including native interoperability. This means that libgdiplus has a (unmanaged) ICO codec and that the System.Drawing.Icon reuse this to provide handle support under Linux (and other platforms using libgdiplus). Under Windows the GDI API is used to support native interoperability. The only known missing, and untested, icon feature are the new Vista icons. They are larger than before (like the rest of the OS ;-) and use another storage format (compressed PNG from what I've read). Actually I'm not sure how, or even if, they are supported by the existing .NET frameworks... considering that GDI+ doesn't seems to like (and neither does VS.NET 2005 really support) the 32bpp icons introduced in XP. Anyway let me know if you have some totally free Vista icons to add to the test suite. Who knows, we could be the first to support them ;-)Poupou's blog, 2007-02-19 04:30:41
I was about to blog about metafiles when I realized I didn't talk, well blog, about icons, so let start with them... Icon support exists in two ways in System.Drawing and libgdiplus. First there's the Icon class which, for some unknown (to me) reason, doesn't inherit from the Image class. This part existed, up to recently, in a fully managed implementation. However this implementation wasn't able to coexist with native code when using handles e.g. Bitmap.FromHicon(icon.GetHandle);. The second place where icons could be used, which was totally missing in Mono 1.2.0, is in the ICO codec. This allows the creation of a Bitmap instances from any ICO file. Well almost any ICO as it turns out GDI+ ICO codec is more limited than what GDI (and System.Drawing.Icon) support (e.g. 32bpp icons). So what's new ? The latest (and greatedt) Mono, version 1.2.3, has full support for both icon cases, including native interoperability. This means that libgdiplus has a (unmanaged) ICO codec and that the System.Drawing.Icon reuse this to provide handle support under Linux (and other platforms using libgdiplus). Under Windows the GDI API is used to support native interoperability. The only known missing, and untested, icon feature are the new Vista icons. They are larger than before (like the rest of the OS ;-) and use another storage format (compressed PNG from what I've read). Actually I'm not sure how, or even if, they are supported by the existing .NET frameworks... considering that GDI+ doesn't seems to like (and neither does VS.NET 2005 really support) the 32bpp icons introduced in XP. Anyway let me know if you have some totally free Vista icons to add to the test suite. Who knows, we could be the first to support them ;-)Poupou's blog, 2007-02-19 04:30:41
More alpha bits
While the ColorMatrix class wasn't widely used it was not the only place where libgdiplus suffered from a lack of pre-multiplication. Loading bitmaps, e.g. 32bpp PNG images, also require to pre-multiply the alpha value to every R, G and B values. Otherwise things starts to look strange or bad. The pre-multiplication process is simple but CPU intensive. It requires, for every pixel (and everyone like bitmaps with a lot of pixels), a division (alpha / 0xff = float) and three multiplications (float * R, G, B). Divisions are slow, so removing the division, using 256 pre-computed floats values (1kb), can have a very visible impact on the required time to apply a ColorMatrix or, more commonly, when loading a transparent bitmap. Time: 0:44.1136470 seconds (see previous benchmark) to Time: 0:40.8741020 seconds I suspect this difference will vary a lot depending on how well your CPU architecture handles divisions. Multiplications are faster than divisions, but we have three of them. Sadly removing the multiplications requires a bigger table, like 65536 bytes (it could be made smaller but would require more time to compute, negating part of the advantage of using a table). This table also removes the need for the previous, albeit a lot smaller, table. New time: 0:35.7004520 seconds That's almost another 20% reduction (45% from the original ColorMatrix). Now is it worth the extra 64kb space in the (already more then 2.5mb) libgdiplus binary ? If it was only for the ColorMatrix then probably not. But we get a lot more comments/bugs on libgdiplus performance than on it's size and loading transparent bitmaps correctly, and without getting (too much) slower, looks worthy enough :-)Poupou's blog, 2007-01-08 04:26:27
While the ColorMatrix class wasn't widely used it was not the only place where libgdiplus suffered from a lack of pre-multiplication. Loading bitmaps, e.g. 32bpp PNG images, also require to pre-multiply the alpha value to every R, G and B values. Otherwise things starts to look strange or bad. The pre-multiplication process is simple but CPU intensive. It requires, for every pixel (and everyone like bitmaps with a lot of pixels), a division (alpha / 0xff = float) and three multiplications (float * R, G, B). Divisions are slow, so removing the division, using 256 pre-computed floats values (1kb), can have a very visible impact on the required time to apply a ColorMatrix or, more commonly, when loading a transparent bitmap. Time: 0:44.1136470 seconds (see previous benchmark) to Time: 0:40.8741020 seconds I suspect this difference will vary a lot depending on how well your CPU architecture handles divisions. Multiplications are faster than divisions, but we have three of them. Sadly removing the multiplications requires a bigger table, like 65536 bytes (it could be made smaller but would require more time to compute, negating part of the advantage of using a table). This table also removes the need for the previous, albeit a lot smaller, table. New time: 0:35.7004520 seconds That's almost another 20% reduction (45% from the original ColorMatrix). Now is it worth the extra 64kb space in the (already more then 2.5mb) libgdiplus binary ? If it was only for the ColorMatrix then probably not. But we get a lot more comments/bugs on libgdiplus performance than on it's size and loading transparent bitmaps correctly, and without getting (too much) slower, looks worthy enough :-)Poupou's blog, 2007-01-08 04:26:27