Bitmap.LockBits fails to work as advertised..... !?

[=?Utf-8?B?VGhlTWFkSGF0dGVy?=]

I dont know if I missed something in documentation,
but I was having a problem with "Bitmap.LockBits" and
was wondering if anyone else has discovered it too.

According to everyones examples including some of
the MVP's website examples, one could use unmanaged
code to manipulate a bitmap by casting the IntPtr from
the Bitmap.LockBits to say an (int*).

The problem I found is that the bitmap would rarely
move around in memory throwing a fault if you were
in the middle of manipulating a bmp.

My application was a cute little scrolling program
doing a 600x800 bmp at about 30fps. It usualy took about
5 to 10minutes before it tanked. (surely directx and
manipulating textures would have been faster, but thats
not the point.)

I found that if I specified the bitmaps data via another
one of the bitmap constructors, then pinning the memory
in the GC then and only then would the program be 100%
stable.

The only thing I know the Bitmap.LockBits does is lock
out a portion of the bitmap to prevent cross threading issues.

Has anyone else had this problem? Any other solutions while
still using pointers to manipulate data?

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

TheMadHatter wrote:

According to everyones examples including some of
the MVP's website examples, one could use unmanaged
code to manipulate a bitmap by casting the IntPtr from
the Bitmap.LockBits to say an (int*).

The problem I found is that the bitmap would rarely
move around in memory throwing a fault if you were
in the middle of manipulating a bmp.

Yes, the bitmap may move around, but that is not a problem as you are
working with a pinned copy of a part of the bitmap data. Or, at least
you should be. If you are trying to manipulate the bitmap data directly,
you would get that problem.

My application was a cute little scrolling program
doing a 600x800 bmp at about 30fps. It usualy took about
5 to 10minutes before it tanked. (surely directx and
manipulating textures would have been faster, but thats
not the point.)

I found that if I specified the bitmaps data via another
one of the bitmap constructors, then pinning the memory
in the GC then and only then would the program be 100%
stable.

The only thing I know the Bitmap.LockBits does is lock
out a portion of the bitmap to prevent cross threading issues.

No, that's not what it does. It copies the data into a memory buffer and
pins the buffer in memory so that the garbage collector won't move it.
The data that you are working with is protected from other threads, but
that is just because the data is local to your thread.

--
Göran Andersson
_____
http://www.guffa.com

[=?Utf-8?B?VGhlTWFkSGF0dGVy?=]

No, that's not what it does. It copies the data into a memory buffer and

pins the buffer in memory so that the garbage collector won't move it.
The data that you are working with is protected from other threads, but
that is just because the data is local to your thread.

That's what I thought it was suppose to do, but on a single thread program,
it still managed to move. I used LockBits at the beginning sub on the entire
area of the bmp, then used unlock at the end. I fail to see the flaw in that.

Thanks for the responce.