Gdi+ Bitmap::FromFile locks file...but why ?

[Patrice]

Hi all,

I'm not trying to solve anything for a change ;-)

I'm using actually .NET but we have a well known "problem" where
Bitmap.FromFile locks the underlying file (and apply the usual "copy"
workaround when needed). I believe this is just because this is done by the
corresponding underlying GDI+ call (hence my post here)

As I'm generally curious I would like to know the reason behind this. This
behavior is documented but until now I never saw someone explaining why it
was designed this way (differed loading ? or the image could be freed and
then reloaded automatically as needed in case of a display mode switch or
something like that ???).

TIA

[Patrice]

Sor for now I just found http://www.xzing.org/?itemid=368 that helps a bit
but not enough explicit yet to my taste.

For now I would say :
- it seems to show that the image is loaded only into video memory. Keeping
the file open would allow to restore the bitmap following a display mode
change.
- not sure if a bitmap created from code is duplicated in system memory so
that it can be restored in vid mem following a mode change (seems to make
sense).

So for now my assumption would be that when a bitmap is loaded from a file,
the file is locked to avoid keeping a system memory copy but still be able
to survive a mode change (by reading from the file again rather than by
restoring a more costly system memory copy).

I'll try to test my assumption unless someone can tell the actual reason...

TIA

[Rene Pilon]

Maybe file mapping - having the file on the hd simulate a memory load where
the file on the hd actually simulates memory? Would saves on memory....

Regards,

Rene Pilon

"Patrice" <http://scribe-en.blogspot.com/> wrote in message
news:%238$MR04NK...@TK2MSFTNGP02.phx.gbl...