[Mono-bugs] [Bug 78285][Nor] Changed - Graphics.DrawIcon memory leak ?

[bugzilla-daemon at bugzilla.ximian.com]

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 sebastien at ximian.com.

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 sebastien at ximian.com  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