Switch to a faster method of capturing the screen.

[JonathanRosado]

I find the performance somewhat lacking, even when set to 'release'. You've mentioned in other threads that the screen capture step is the most time consuming (40ms). This can be improved by using more efficient methods.

Some possible solutions include using DirectX and reading from the front buffer or back buffer. Or use Windows Media API for capturing the screen. I think either of these would offer superior performance to GDI.

[jpxue]

I've tried capturing from the front buffer and noticed that it was more or less the same as using GDI (actually a few ms slower in my case).

Capturing directly from the back buffer would surely be the fastest option yes. I'm no Direct3D expert but I'm positive that you cannot access the backbuffer without injecting and hooking Present or EndScene which will inadvertently significantly increase your chances of getting banned so I did not even consider this option.

As for the Windows Media API, I do not know a thing about it. If it compresses the image it could cause a problem when finding the health bar seeing that it looks for specific RGB values which could change on compression. I also did not manage to find anything about it's performance vs GDI or Direct3D so I have no idea. If I had time, I would try it; providing that it is not a layer that still interfaces with GDI behind the scenes.

At this point, the capture algorithm could be improved by shrinking the size of the area to be captured. It is very simple to implement just by changing a few parameters when defining the HBITMAP and when calling BitBlt. Improving the mouse movement algorithm would also be a priority because it takes 3 cycles to get the mouse to where it actually should be thus the speed could be cut by 3x in this regard.