views:

46

answers:

3

Hello,

Is it possible to use the FromStream method of System.Drawing.Image without having to keep the stream open for the lifetime of the image?

I have an application which loads a bunch of toolbar graphics from resource files, using a combination of Image.FromStream and Assembly.GetManifestResourceStream.

The problem I'm having is while this works fine on Windows 7, on Windows XP the application crashes if a user interface element linked to one of these images is disabled. On Windows 7, the image is rendered in grayscale. On XP, it crashes with an out of memory exception.

After a load of hairpulling I have finally traced it to the initial loading of the image. As a matter of course, if I create any object implementing IDisposable that is also destroyed in the same method, I wrap it in a using statement, for example

    using (Stream resourceStream = assembly.GetManifestResourceStream(resourceName))
      image = Image.FromStream(resourceStream);

If I remove the using statement so that the stream isn't disposed, then the application no longer crashes on XP. But I now have a bunch of "orphan" streams hanging about - the images are stored in command classes and these correctly dispose of the images when they themselves are disposed, but the original stream isn't.

I checked the documentation for FromStream and it confirms the stream needs to remain open. Why this hasn't crashed and burned on the Windows 7 development system is a mystery however!

I really don't want this stream hanging around, and I certainly don't want to have to store a reference to this stream as well as the image so I can dispose of it later. I only have need of that stream once so I want to get rid of it :)

Is it possible to create the image and then kill of the stream there and then?

Thanks;
Richard Moss

A: 

You could save the stream to a temporary file and use the Image.FromFile method. Or simply don't embed the image, keep it as a file and load it from this file at runtime.

Darin Dimitrov
Thanks for the answer, although this is something I'd already discarded, as I know from past experience that this locks the file therefore wouldn't be able to delete it until the application ended.
Richard Moss
A: 

According to the documentation of Image.FromStream, the stream must be kept open while the image is in use. Therefore, even if closing worked (and there's nothing to say you can't close a stream before it's disposed, as far as the stream object itself goes) it may not be a very reliable approach.

You could copy the image to another image object, and use that. However, this is likely to be more memory intensive than just keeping the stream open.

Jon Hanna
Thanks for the answer. This is what I've gone with, using the KB article linked above which provided the reasons why.
Richard Moss
It does also detail while it may be more efficient to hold onto the stream in some cases, which is worth bearing in mind.
Jon Hanna
+1  A: 

The reason the stream needs to be open is the following:

GDI+, and therefore the System.Drawing namespace, may defer the decoding of raw image bits until the bits are required by the image. Additionally, even after the image has been decoded, GDI+ may determine that it is more efficient to discard the memory for a large Bitmap and to re-decode later. Therefore, GDI+ must have access to the source bits for the image for the life of the Bitmap or the Image object.

The documented workaround is to create either a non-indexed image using Graphics.DrawImage or to create an indexed Bitmap from the original image as described here:

Bitmap and Image constructor dependencies

0xA3
Thanks for the extremely useful answer! I knew about FromFile locking files, but I never knew the reason why until now. I've tested using the Create a Non-Indexed Image approach which has worked fine, and the application is no longer crashing on my XP VM. I'll test again using the Indexed approach and see what happens - I'm unclear on the difference between the two types.
Richard Moss
Fwiw: they fixed several problems with indexed pixel formats in the Vista version of gdiplus.dll. Nice of them to do so, but a headache when your code needs to run on XP. In general, stay away from them to avoid this trouble.
Hans Passant