Why HBITMAP use so little memory?

I met an interesting question:

1. load a big (4500x6000) jpeg into memory (RGBRGBRGB....) by libjpeg (cost about 200M memory)
2. CreateDIBitmap() to create a HBITMAP from the data
3. free the memory used

now I found that the process use only 5M memory at all. I wonder where is the data of the HBITMAP. (I disable pagefile)

update:

I write such code for testing:

    // initilise 
    BITMAP bitmap;
    BITMAPINFO info;
    // ....
    void *data = NULL;
    HDC hdc = ::GetDC(NULL);
    HBITMAP hBitmap = ::CreateDIBS开发者_开发技巧ection(hdc, &info, DIB_RGB_COLORS, &data, NULL, 0);
    ::ReleaseDC(NULL, hdc);

    if (hBitmap) {
        ::GetObject(m_hBitmap, sizeof(bitmap), &bitmap);
    }

Then the data is 0x2d0000 (surely in user space), bitmap.bmBits is also 0x2d0000. So I make sure that CreateDIBSection use user space memory for bitmap.

How about this for a test. Create HBITMAPs in a loop. Counting the number of bytes theoretically used (Based on the bitdepth of your video card).

How many bytes worth of HBITMAPs can you allocate before they start to fail? (Or, alternately, until you do start to see an impact on memory).

DDBs are managed by device drivers. Hence they tend to be stored in one of two places :- kernel mode paged pool or in the Video Cards memory itself. Both of which will not be reflected in any process memory count. In theory device drivers can allocate system memory storage for bitmaps, moving them across to vram as and when needed... but some video card drivers think that video memory should be enough and simply allocate all HBITMAPs on the card. Which means you run out of space for HBITMAPs at either the 2Gb mark (if they're allocated in kernel paged pool; depending on available ram and assuming 32bit windows editions), or 256Mb mark (or however much memory the video card has).

That discussion covered Device Dependent Bitmaps.

DIBSections are a special case as they're allocated in memory accessible from kernel mode, but available in userspace. As such, any application that uses a lot of bitmaps probably should use DIBSections where possible as there should be much less opportunity to starve the system of space to store DDBs. I suspect that one still has a system wide limit of up to 2Gb worth of DIBSections (on 32bit Windows versions) as there is no concept of 'current process' in kernel mode where the video device drivers will need access.