Question

When loading an image into memory, does .Net use DDB, DIB, or something else entirely? If possible, please cite your sources.

I’m wondering because we currently have a classic ASP application that is using a 3rd party component to load images that is occasionally creating a “Not enough storage is available to process this command.” error. The error is very inconsistent but tends to happen on larger images (not always, but often). After resetting IIS, processing the same file again typically works just fine.

After much research I have found that DDBs tend to have this problem when processing large images because they work out of video memory. Considering that we are running on a web server with an integrated video card and limited shared memory, this could certainly be our problem.

We are in the early stages of converting our app to .Net and am wondering if using .Net for this might be a viable alternative to our current method which is why I am asking the question.

Any advice is welcome 🙂 but out of curiosity if nothing else, I am really hoping for an answer to the question; does .Net use DDB or DIB?

Answer 1

Disclaimer: my answer is possibly relevant only to pre-WPF .NET (but the same concepts apply to both).

The answer to your headline question is “both”. The System.Drawing namespace includes a handy Bitmap class that is essentially a DIB (or Device Independent Bitmap). The Bitmap class includes a GetHbitmap method which creates a DDB (or Device Dependent Bitmap) in-memory copy of the original DIB and returns a handle to it.

The DDB handle can be selected into a device context (which lets you use the super-fast BitBlt API method). Or you can just never create a DDB in the first place, and do all of your graphics operations with pure .Net (the best way, IMO). GetHbitmap is a relatively dangerous method, as you have to call DeleteObject on the handle it returns in order to free up its memory when you’re done with it (it’s the only example I can think of where a .Net method requires a PInvoked API call in order to function correctly). Also, because the method returns an IntPtr, programmers tend not to realize that when it’s called the OS has to carve out another chunk of memory equal in size to the original .Net (DIB) bitmap.

So the answer is: .Net uses DIBs, but can use DDBs if necessary. Or worse, when not necessary. I’ve actually inherited more than one .NET web app that used GetHBitmap without the matching DeleteObject call, producing one long memory leak.

You have a broader question, though, which is: can a .Net application running on a server reliably process a large volume of large image files without crashing the server? The answer is yes, so long as you really understand what the .NET framework is doing under the hood with image manipulation. .NET graphics classes encapsulate a lot of the grisly details away from the programmer, and some ways this is kind of bad because it makes it less likely that a programmer will learn what’s really going on.

Edit: forgot to include this important disclaimer from MSDN:

Caution

Classes within the System.Drawing
namespace are not supported for use
within a Windows or ASP.NET service.
Attempting to use these classes from
within one of these application types
may produce unexpected problems, such
as diminished service performance and
run-time exceptions.

Translation: “you’re probably going to screw this up – don’t say we didn’t warn you”. It’s fundamentally sound advice, because these classes – while very powerful and utile – are also dangerous. It’s extremely easy to consume some resource and fail to release it properly, or to use the classes in a way that results in massive memory consumption. Sometimes these problems are not large in a desktop application, but in a heavily-loaded web server serving multiple requests simultaneously it can become a huge problem.

I think they can be used safely in this context, however, or to put it a little differently, I think they can be used as safely as anything else if you’re trying to process a large number of sizable bitmaps on a web server at the same time. However, I would make certain that I heavily load-tested my web site code before going live to production.

Update 1: The following quote (with link) applies to bitmaps in the .NET Compact Framework, and I do not think it applies to the full framework (I’m mainly including it here for general reference – i.e. so I can find it again myself someday):

Here is a little deeper information on
the way [.NetCF] Bitmaps may be allocated.
There are two major paths for
allocation which may affect where the
memory is allocated, but in the end
have the same issues as indicated
above.

1. Bitmap constructor that takes a stream
   as a parameter [i.e. loads from a file]
   • This will construct a DIB
   • DIBs are allocated out of the application process virtual memory
     (VM) address space
2. Bitmap constructor
   that takes a height/width as
   parameters
   • This will construct a DDB
   • DDBs are allocated by the driver, typically, in the gwes.exe or possibly
     in dedicated video RAM. This will
     actually use physical and virtual
     memory that is not in the process VM
     space.

In short, we have 2 different types of
Bitmap in our runtime with varying
performance and allocation
characteristics. DDBs are generally
faster to manipulate and draw to the
screen than DIBs, but they are
constructed in an external memory
space that can cause allocation
confusion and cause the performance of
calls to LockBits or Save to be
slower. If a DIB is desired and you
wish to construct it based on width
and height, we provide a function that
constructs a Bitmap with a width,
height, and pixelformat specified.
This function will construct a DIB
instead of a DDB.

More information (still just on .NetCF bitmaps) here:

http://blog.opennetcf.com/ctacke/PermaLink,guid,987041fc-2e13-4bab-930a-f79021225b74.aspx

Update 2: some links relevant to .NET bitmaps in the full framework (summary at the bottom):

http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-performance/1187/Graphics-FromImage-Process-memory-usage

http://www.netframeworkdev.com/common-language-runtime/memory-issues-with-systemdrawingbitmap-30879.shtml

http://www.west-wind.com/WebLog/posts/8230.aspx

http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.drawing/2005-06/msg00171.html

Summary: I think this question is difficult to answer because, basically, this (the actual location of the memory used by Bitmap) is an internal .NET implementation detail, mostly undocumented for a good reason. Since it appears that you can’t really be sure where the bitmap’s memory lives right now, and you definitely can’t be sure where it will live in the future, I’d have to say MSDN probably wasn’t kidding when they said:

Caution

Classes within the System.Drawing
namespace are not supported for use
within a Windows or ASP.NET service.
Attempting to use these classes from
within one of these application types
may produce unexpected problems, such
as diminished service performance and
run-time exceptions.