Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78285 --- shadow/78285 2006-05-04 12:21:47.000000000 -0400 +++ shadow/78285.tmp.25233 2006-05-04 15:10:19.000000000 -0400 @@ -41,6 +41,28 @@ ? A little test like "if (icon_bitmap != null) return icon_bitmap;" in ToBitmap () should be enough. If the bitmap is null we create it again. With that method we do not need to create a new bitmap all the time for Graphics.DrawIcon which saves some time when it get's called from System.Windows.Forms (ThemeWin32Classic DrawStatusBarPanel for example). + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-04 15:10 ------- +Keeping a reference won't tell us if it's disposed or not. We can peek +inside (e.g. the handle) to know if it's disposed - but that wouldn't +be thread safe as the bitmap could be disposed during the time we're +drawing it. Sure we could add a lock but that's a lot of code/possible +bugs without any hard data about the gains... + +If it's worth it (and I'm don't know enough to say it is, or not) I +think that returning a clone bitmap of a cached bitmap (that no one +else can dispose) would be faster than the current ToBitmap() code. + +An alternative could be to have an internal method similar to ToBitmap +(e.g. GetCachedBitmapReference) that would return a reference to the +cached bitmap (creating it if required). That would be ok because we +would be the only callers (hence no dipose problem). Then the existing +ToBitmap code could re-use the new method and return a Clone of it (to +reduce code duplication). + +It would be nice if you could attach some profiling data showing how +much time/memory is spent in Icon.ToBitmap for a typical application. +Thanks _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
