CreateDIBSection in the application memory

Question

Hi, 

In my application uses DIBs to cache bitmaps for very fast drawing.

I know that CreateDIBSection allocates memory on the kernel's shared memory, and this is where my problem begins: when the cache becomes big other program starts to crush including mine.

I saw that in GDI+ Bitmaps/TextureMap are stored in the application memory space, 
Is there any way to use my application memory space for the DIBs? (using CreateFileMapping is not an option because it will make my application slow).

Thanks,
Roey

Answer 1

In my understanding on the document the memory is system allocated if the hSection parameter is NULL, so I think we cannot let it user the application process space.

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 2

Can you please provide more details about the System Memory? how can i much of it is free? and etc...

Answer 3

Roey wrote:

>

>In my application uses DIBs to cache bitmaps for very fast drawing.

>

>I know that CreateDIBSection allocates memory on the kernel's shared

>memory, and this is where my problem begins: when the cache becomes

>big other program starts to crush including mine.

>

>Is there any way to use my application memory space for the DIBs?

>(using CreateFileMapping is not an option because it will make my

>application slow).

 

That's nonsense.  What on earth leads you to think that CreateFileMapping

will have ANY effect on performance?  Creating a file mapping backed by the

page file is exactly identical to allocating memory from the heap.  It's

just a hunk of memory.

--

Tim Roberts, [e-mail]

Providenza & Boekelheide, Inc.

 

---

Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

Answer 4

Hi Tim, 

Thanks for you reply :)

I guess "backed" by the page file in the documentation is not that obvious...  i thought it worked the same way as a regular file, but instead of a file on mine, the system page file (i also read in an article that this is the case).

But,
Maybe there is a reason after all it was decided to allocate the DIBs in the system's memory? (performance reason?)

Thanks,

Roey

Answer 5

Sorry, I'm not a GDI aspect expert(I hope I become to be :)),

Maybe I'm not very understanding the document, I should admit that I cannot explain the "system memory".

But in some articles and books has the DIB section memory management discussion, I saw that the "DIB section is allocated from the application's virtual memory space, or memory-mapped file. The size is only limited by the virtual memory space and the free disk space." 

http://books.google.com/books?id=-O92IIF1Bj4C&pg=PA657&lpg=PA657&dq=DDB+DIB+virtual+memory&source=bl&ots=SxYFH3cdn6&sig=jb67vsc5kWRQlTh8G9mDEjHlMh0&hl=en&sa=X&ei=b41QT_2xLoj3rQfcgZ23DQ&ved=0CEAQ6AEwAg#v=onepage&q=DDB%20DIB%20virtual%20memory&f=false

And in this page, it also said that, "Without a DIB section, you have to create a DIB and a DDB",(the DDB memory is from the kernel mode address space).

And I think you can use the Memory-Mapped File[A memory-mapped file contains the contents of a file in virtual memory.]

All the content is in the virtual memory, so I think it will not affect your application performance.

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 6

Thanks for the answer Mike.

At the end i realized that i just shouldn't use so many DIBs and i'm cleaning my textures cache every time the display changes (and also setup an emergency clean, if the creatdibsection fails).

Thanks guys!

Answer 7

Roey wrote:

>

>I guess "backed" by the page file in the documentation is not that

>obvious...  i thought it worked the same way as a regular file, but

>instead of a file on mine, the system page file (i also read in an

>article that this is the case).

 

Sort of.  Let me see if I can build you a mental model.

 

(Except for the exceptional cases of locked memory) **ALL** memory is

backed up on disk somewhere.  Really, the basic principle of a virtual

memory system is that virtual memory lives on disk, and some pieces of it

happen to be resident in physical memory at any given time.  If you

allocate heap memory with malloc, and the system comes under memory

pressure, that part of the heap is going to be swapped out to disk.  In

this case, it goes to the page file (hence "backed by the page file").

 

When you load a DLL, exactly the same process occurs, except that the

memory is "backed by" the DLL file.  If memory pressure rises, the DLL will

be swapped out (although since the memory hasn't changed, nothing is

actually written to the disk).

 

Memory-mapped files are just a way to gain access to that exact mechanism.

When you allocate a memory mapped file, the information lives in memory

until the system comes under memory pressure, at which point it might get

swapped out (if it hasn't been touched).  The advantages of a memory-mapped

file are that a single chunk of memory can be mapped into many processes at

once, and you can have the backing go to a named file of your choice

instead of the page file.

 

Memory-mapped files hook into the paging system, which is among the most

highly optimized modules in the entire kernel.

--

Tim Roberts, [e-mail]

Providenza & Boekelheide, Inc.

 

---

Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

Answer 8

Thanks Tim!

I understand now,

Why do you think Microsoft is not backing up DIBs in virtual memory by default (like it does in GDI+ Bitmaps)?

Roey

Answer 9

You're welcome.

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 10

Welcome? Is this Tim?

Answer 11

Roey wrote:

>

>Why do you think Microsoft is not backing up DIBs in virtual memory

>by default (like it does in GDI+ Bitmaps)?

 

I'm not sure that they aren't.  GDI first tries to allocate DIBs in

graphics card offscreen memory, because that results in more efficient

drawing.  If that's full, it falls back to system memory.

--

Tim Roberts, [e-mail]

Providenza & Boekelheide, Inc.

 

---

Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

Answer 12

I had another idea about why they didn't use virtual memory:
Maybe they thought that it's better to retun null and notify the program the V/RAM is full and that the application should try to free some of it, so that performance won't be affected.

Thank you very much for your time Tim!