Lockbits vs BitBlt

[_DD]

I've heard that fast bitblt functions still need to resort to calling
older Bitblt vs interop. Has this changed? Will GDI+ Lockbits come
close to the speed of GDI BitBlt?

 

[Bob Powell [MVP]]

The two principles are totally different.

BitBlit and incidentally DrawImage is for copying an image in memory to
the graphics object. Either a graphics device such as a screen or a
second in-memory graphics object.

LockBits enables direct access to the image byte array without the need
to go through the less efficient bitmap image APIs. Access in this way
is fast and unsubtle.

Where LockBits even approaches the philosophy of BitBlit is when a
direct image to image copy operation is needed. In this case LockBits
may be used to access both memory buffers and data transferred from one
to the other. Any form of clever image processing in this transfer
begins to approach the inefficiency of DrawImage if any processing is
done on the image data.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[_DD]

The two principles are totally different.

BitBlit and incidentally DrawImage is for copying an image in memory to
the graphics object. Either a graphics device such as a screen or a
second in-memory graphics object.

LockBits enables direct access to the image byte array without the need
to go through the less efficient bitmap image APIs. Access in this way
is fast and unsubtle.

I didn't explain the intent very well. A closer analogy would have
been 'DibSection + BitBlt' vs 'LockBits + DrawImageUnscaled.'
I'm thinking about revisiting an app that I worked on ages ago in olde
C++ (seems way too long ago).

Where LockBits even approaches the philosophy of BitBlit is when a
direct image to image copy operation is needed. In this case LockBits
may be used to access both memory buffers and data transferred from one
to the other.

That's about it. The app basically builds a screen behind the scenes
by stamping graphics images into ram, cookie-cutter style. Envision
something like an schematic cad system with preset resistor and
capacitor symbols in monochrome bit patterns. Not an animation, per
se, but I need to do a complete BitBlt on a large window.

If memory serves, I was using DibSections and/or a 'magic'
undocumented ROP, 0xE20746, which does the cookie cutter thing quite
efficiently (Not sure why that was not documented).

In the interim, I've written some C# code where I had to do something
vaguely like that. I ended up using Lockbits to access ram and stamp
the pattern, then DrawImageUnscaled() to blt it.

I've heard that to get sufficient speed that C# programmers are still
Interop'ing older Dibsection/BitBlt calls. Can LockBits get close to
that speed? Maybe I should just be thinking DirectX, but this is
almost like a schematic cad program, not a game.

[re Lockbits]

Any form of clever image processing in this transfer
begins to approach the inefficiency of DrawImage if any processing is
done on the image data.

You got me there. I thought that would be the fast part.

 

[_DD]

using LockBits and unsafe code:
Is it suppose to actualy lock the data in memory???????

I found out the bitter way that it is safer to create the
bitmap data, pin it, and wrap the bitmap class around it.
That way it was ptr safe. LockBits alone isnt "safe".

What the lockBits for then?????
Is it simular to lock(someObj) ???????

It will be interesting to hear what Bob says about that, but I thought
LockBits was supposed to do something like what you described above.
However, I do have an app that uses LockBits where the display
flatlines once in a while. I had NOT attributed that to LockBits or
memory reallocation, but it's so sporadic that it's tough to trace
(does not happen under the debugger).

Do you have places where you know that Lockbits has failed to keep ram
from being moved?