MBR IT/.NET 247 : BitBlt Managed Version on microsoft.public.dotnet.framework.drawing

BitBlt Managed Version

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.drawing.

assaf

hi all

i am porting some code from C++.
i have two bitmaps.
i am using BitBlt to transfer pixels from one to the other.

now, in dotnet, i have again, two bitmaps,
but i don't know how to transfer pixels from on to the other.

so what exactly to i do?

assaf

Reply to this message...

James Westgate

Hi,

You can either use bitblt to draw from one bitmap to the other, see

http://support.crainiate.net/?s=Knowledge%20Base/Control%20Creation%20FAQ/bitblt.html

or you can simply gets a graphics object from the target image use

Graphics g = graphics.FromImage(target);
g.DrawImage(source);

James

--
Create interactive diagrams and flowcharts with ERM Diagram at
http://www.crainiate.net

Take the ERM Tour at http://www.flowchartcontrol.com

"assaf" <Click here to reveal e-mail address> wrote in message
news:uEO0R$Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

assaf

hi james.

which is more efficient?
BitBlt or g.DrawImage()?

assaf

"James Westgate" <Click here to reveal e-mail address> wrote in message
news:#Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

James Westgate

Hi

Bitblt is nearly always faster but it means that your code is not 100%
managed. It depends on your bitmap and the drawmethod you use. For best
results use 32pargb bitmaps (specified on the bitmap constructor) and
DrawImageUnscaled instead of DrawImage. This is due to the fact that GDI+ is
not hardware accelerated.

James

"assaf" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

assaf

hi james.

i would like to describe to you my issue,
and ask for your opinion.

my app is a remote learning application
that allows many students to view the teacher's desktop.
it is written in C#.NET with a lot of InterOp stuff.

the student's client receives small bitmap updates from the server.
these are the desktop updates from the teacher which represent
changes in his desktop.

when each bitmap arrives, we update the studet's client's window.
we are currently updating the student's window's bitmap with
LockBits, and memcopy
however, this is turning out to be rather slow, and CPU intensive,
as we need to loop through all the lines making up the small bitmap.

so, we are looking to speed things up.

if you had a large bitmap that you needed to
constantly update its different areas with new small bitmaps,
how would you go about this?

assaf

"James Westgate" <Click here to reveal e-mail address> wrote in message
news:O#Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Steve McLellan

Hi,

BitBlt is faster than DrawImage. It's significant if you need to do anything
like realtime, but it does require more coding work. DrawImage is much
easier, and it's generally ok for speed IF you use the 32bppPArgb format
(otherwise it's astonishing slow).

Steve

"assaf" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

James Westgate

I would use bitblt through interop. See link I posted earlier in thread.

J

"assaf" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

assaf

hi guys.

thank you both james and steve.
but i am not sure u understand my question.

i have a window with a large (desktop size) background image.
this image is constantly being updated with small bitmaps.

we are using LockBits and MemCpy for this updating.

we are not overriding OnPaintBackground nor the Paint event.
instead, we are letting the background image display naturally.

my question is twofold:
1. is it ok to be using memcpy for updating the background image?
2. is it ok to use the backgound image property and let it display naturally
a constantly updating bitmap?

tnx again
assaf

"James Westgate" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Steve McLellan

[Original message clipped]

Hi,

Are your small bitmaps showing the full image in a smaller space than the
original, or are they views onto it? And what's forcing the constant
updating? Using memcpy is OK if you're sure that the destination and source
images are identical in the sense that they're at the same bit depth, same
size, same format etc. Otherwise you'll get problems. BitBlt is essentially
a memcpy, except that it's capable of drawing to any device context and not
just areas of RAM. If you can give me more details on what's causing things
to update and exactly what these smaller bitmaps are it'll be easier to
advise something. If you're getting slow speeds with memcpy I'd be extremely
surprised - my guess would be that the Image you're giving to the background
image property is not of the right format - for fast displaying you need to
be using PixelFormat.Format32bppPargb.

Cheers,

Steve

Reply to this message...

assaf

hi steve.

we have created our own Pc Anywhere.
only in C#.NET.

we have two sides to our app:
a 'controlled' computer - where we capture screen changes and send them out.
and a 'controller' computer - where we receive screen updates and display an
updated bitmap of the 'controlled' computer.

the incomming bitmaps, are the 'controlled' screen updates.
we take each small bitmap and copy its pixels onto the large 'view' of the
"controller"'s display.
we are using memcopy for this.
this is not efficient as we have to loop through each line seperately.

would BitBlt make it faster?
and if yes, what would such code look like?
(i am not keen on GDI API)

tnx so very much sir.
assaf

"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Steve McLellan

Hi,

Like I said, BitBlt essentially is a memcpy, except that you're able to copy
onto bitmaps, the screen, the printer, anywhere. If I were you I would use a
panel and manually paint stuff onto the screen; at the moment, you're
essentially doing:

Receive bitmap -> Copy to background Image -> Copy to screen

Instead, copying from the received bitmap to the screen will be quicker. If
you want to do this, you have two options: use DrawImage, or use BitBlt. If
I were you, I would look at DrawImage first since it's very easy to
implement and you might be able to get it fast enough. It's EXTREMELY
important that the image you give to DrawImage has PixelFormat 32bppPArgb,
or it'll be very slow.

If you don't want to paint directly to the screen, or you want to store the
received bitmap, then memcpy is about as fast as you'll get. All BitBlt will
do is copy scanline by scanline. Even copying a huge image should be
lightning fast with memcpy - efficient memory access takes no time. However,
you will need to use unsafe code to get decent performance out of it. If you
can paste the bit where you do the copy I might be able to help you speed it
up. I'd also advise getting a decent profiler, since there might be
bottlenecks somewhere you don't expect.

So, to clarify: 1) Make sure your bitmaps are 32bppPArgb, 2) Decide whether
you are able just to receive the bitmap, then paint straight onto a Control,
3) If you are able, try DrawImage, 4) Profile everything.

HTH,

Steve

"assaf" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

assaf

hi steve.

tnx for all your effort.

1. it would not make sense to BitBlt the received bitmaps onto the screen.
as they overlap each other, it would be very wastefull
to draw all of them (growing number) all the time.

2. we DllImport'ed memcpy.
is using fixed memory any better?

3. when we capture the screen bitmap (in the controlled computer),
we do not control the PixelFormat.32bppPArgb
i included our capture code at the end of this message.

4. we will profile.

assaf

public static Bitmap CaptureScreen(Rectangle r)

{

// get a handle to the 'source' window

IntPtr d = User32.GetDesktopWindow();

// get the 'source' device representing the window

IntPtr hdcSrc = User32.GetWindowDC(d);

// get the source device resolutions

int width = GDI32.GetDeviceCaps(hdcSrc, DeviceCaps.HORZRES);

int height = GDI32.GetDeviceCaps(hdcSrc, DeviceCaps.VERTRES);

// create an *EMPTY* compatible bitmap for the destination device, with a
smaller then the source size

IntPtr hBitmap = GDI32.CreateCompatibleBitmap(hdcSrc, r.Width, r.Height);

// create a compatible destination device (with a bitmap of the source
device - too big)

IntPtr hdcDest = GDI32.CreateCompatibleDC(hdcSrc);

// select the compatible bitmap into the destination device, this bitmap has
the correct size

GDI32.SelectObject(hdcDest, hBitmap);

// now copy the bits, only for the rectangle requested

GDI32.BitBlt(hdcDest, 0, 0, r.Width, r.Height, hdcSrc, r.Left, r.Top,
BitBltRop.SRCCOPY | BitBltRop.CAPTUREBLT);

GDI32.GdiFlush();

// * now the hBitmap contains the pixels *

// create a .NET managed object from the hbitmap

Bitmap b = Image.FromHbitmap(hBitmap);

// clean up

User32.ReleaseDC(d, hdcSrc);

GDI32.DeleteDC(hdcDest);

GDI32.DeleteObject(hBitmap);

return b;

}

"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
news:O$Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

	System.Drawing.Imaging.PixelFormat
	System.IntPtr
	System.Web.UI.MobileControls.Image

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com