BitBlt And CPU 100%

[Fraile]

Hi,

I am trying to implement a Win32 screen capture application similar to VNC.
The issue is, the Bit blt function call that i am using to capture the screen chokes up the cpu when the hardware acceleration is FULL. The Cpu goes upto 100% and stays there.

I tried BItBlt on the HDC obtained from CreateDIBSection and CreateCompatibleBitmap funtions, but both gave the same result.

When i set the Hardware acceleration to NONE the cpu utilisation is atmost 30%.

Is there any way that i can reduce the BitBlt CPU usage when hardware accleration is set to FULL.

How disabled hardware acceleration with API?

Please help.

Thanks,

[dedndave]

you didn't show us any code
but, i can guess what the problem is
you handle the WM_PAINT message without validating the update region
it will continually send WM_PAINT messages until the region is updated
one way to avoid this is to call BeginPaint and EndPaint
another way is to exit WndProc via DefWindowProc for WM_PAINT messages
still another way would be to call ValidateRect

[Fraile]

Correct, I handle  to message "WM_PAINT". Attached code Hook.

When detect "WM_PAINT", sent a message for capturing screen.

Please could you explain with my example?

Thank you very much

[dedndave]

i don't know what you're tring to do, there   :P

but, give me a few minutes, and i will post a simple example using WM_PAINT, BeginPaint, EndPaint

[dedndave]

see attached...

[Gunther]

Hi Dave,

good catch.  :t I hope it'll help our friend.

Gunther

[Adamanteus]

 I not very clear understand you code, but by concepts could remark - BitBlt algo making few MFLOPS processing all pixels, so easy could overload processor. For avoiding it is need to split algo on more smaller parts, that's running in threads, meanwhile main thread calling Yield function waiting results - so, you need to manually rewrite you version of BitBlt (suppose even part of it), and support this processing big (attended to time when original code was written) resolution of modern screens.

[Farabi]

AFAIK, WM_PANIT sometime called hundreds time a seconds and that is why it make your CPU usage goes to 100%. I used to limited the Bitblt to 60 FPS, and bitblt is very efficient compared than creating your own using the CPU. Bitblt is hardware accelerated, even on my old zyrex EGT there is only bitblt which is hardware accelerated, and OpenGL used it too to create the texture maping.

[Fraile]

Thank to All,

Sorry my english is very bad.

I capture  the screen in several frames, but the cpu performance is up 100%. I divide the screen into columns and rows.

I thinks as Farabi says: "WM_PANIT sometime called hundreds time a seconds "

Farabi, how limit "BitBLt" to 60 FPS?
Is best to use timer in lieu of a hook?

[dedndave]

multimedia timers are a bit more complicated, but provide higher resolution
the standard windows timer has a resolution of either 10 or 16 mS, depending on the system
if you want exactly 60 FPS, you'll have to use the multimedia timer resolution of 1 mS and fudge

[MichaelW]

The timeBeginPeriod function sets the minimum resolution for all of the periodic timers, not just the multimedia timers. But if CPU usage is a problem, setting a higher resolution for the periodic timers will likely make the problem worse.

To limit the frequency of an event, you could poll a suitable timer in your message loop. QueryPerformanceCounter is one possibility.

[jj2007]

If your WM_PAINT message is coming too often, it's a design problem.

Anyways, check pDueTime in SetWaitableTimer.

[Fraile]

You could give a example to  " SetWaitableTimer"?

Please, thank you very much.

[Fraile]

You could give a example to  " QueryPerformanceCounter"?

Please, thank you very much.

[jj2007]

You could give a example to  " SetWaitableTimer"?

Try this.
BTW, in your hook code I see
                .elseif [edx].message  == WM_KEYDOWN
                    invoke PostMessage, HWND_BROADCAST, HwdMensaje,0,0

... shouldn't that be
                    invoke PostMessage, HWND_BROADCAST, HwdMensaje,wParam,lParam
??? You want to know which key was pressed, right?