asked on

faster than BitBlt

Hi all,
In my program i am capturing a part of the screen and saving it as a bitmap.
I am using BitBlt to get the contents of the screen. On my machine, i noticed that
BitBlt() takes about 170ms to execute. Is there a faster alternative to Bitblt().
Appreciate the help.
Thanks,
Preetham.

ASKER CERTIFIED SOLUTION

DanRollins

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

preetham_mp

ASKER

Thanks Dan,
I ran spy and found that there is no call to WM_PAINT
I am using the code.
//******************************************
hWndApp =GetForegroundWindow();
appDC =GetWindowDC(hWndApp);
GetClientRect(hWndApp, &appRect);
hbitmap =CreateCompatibleBitmap(hdcscr, int(appRect.right - appRect.left),int (appRect.bottom - appRect.top));

SelectObject(hdcmem, hbitmap);
BitBlt(hdcmem, 0, 0,abs(appRect.right - appRect.left), abs(appRect.bottom - appRect.top), hdcscr, appRect.left, appRect.top, SRCCOPY );
//*******************************************
I am runnning an AMD 1.3G, 512RAM, ATI 3d grahics card machine, does the hardware make the diff, particularly the AMD processor.

SOLUTION

Madshi

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

DanRollins

If you are capturing the screen of a window that is owned by another application, there may be considerable overhead in marshalling all of that data from one process to another. That is just a guess... If that is the problem I cannot suggest a reasonable solution (I suppose you could write a WindowsHook so that your DLL was injected into the target process, but that seems like overkill and not too likley to work anyway). Or perhaps you could transfer it to the clipboard, which is optimized for similar operations (Test: Press Ctrl+PrintScreen and measure the elapsed time).

-- Dan

SOLUTION

joghurt

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

DanRollins

>>The standard "memcpy" library function can be written more than 13-times faster (!) compared to the Microsoft version.
Perhaps you are looking at the Debug (call-based) version of memcpy or perhaps you did not examine the optimized inline (intrinsic) version. I'd love to see proof of that assertion.

>> Not a big trick if you know what are you doing.
And the programmers at Microsoft are complete fools?

Anyway, your implication is that the device driver was written by the "fools" at Microsoft and so should thus not be expected to be fast. It is my understadning that most video device driver are written by OEMs, who have an enorous financial stake in providing the fastest code.

<Dan/>

SOLUTION

danielsson

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

DanRollins

>> Is there a faster alternative to Bitblt().

With this discussion of slow-speed to read video memory, it occurred to me that perhaps there *IS* a faster method.

If you can get the window to draw itself into a memory DC, there is at least some chance that that *might* be faster than blitting from the hardware. If you send the WM_PRINTCLIENT message to a window, passing in a memory HDC, then that would be one way to find out. It doesn't seem to likely, but it might be worth trying.

-- Dan