Multiclient is doable even in this caseQuote:
Multi-Client support won't be possible if you're going to support multiple servers and let the users themselves add support for a server. Doing it multi-client you'd either require the /awake command or calling the awake function itself from memory. So multi-client isn't an option in this case.
Don't really know what you mean by "without need of any real OCR". The OCR library I use is not known for it's speed but has good accuracy instead. If speed was super important I'd probably not use Tesseract and some other engine instead.
The reason I've made it so there's a delay instead of waiting for the awake to change would be because there's a chance of the awake being the same as the one before. Then it'd get stuck waiting for the awake to change. Sure, you can add some code that makes it continue after a while if it still hasn't changed. But, the current way works fine aswell. As I said, such small small changes ain't going to affect it since it has to wait for the scrolls and click with the mouse and shit.
If the benchmark including the screen capture was 5 ms, you've had to use DirectX and / or capturing a very small piece of the screen. But it sound too good to be true with C#, but probably possible though.
- align click coords (move window interop)
- send all clicks simultanously on all clients
- take and process results (focus window interop)
You might loose few miliseconds per each client, but in fact your still left with 98% gain on awakes/client.
I didnt need OCR cause i preprocessed any awake texts to find markers and only had to compare few pixels manually.
For faster reading you use unsafe directives and retain pointer that can reread pixels without any overhead.
For "same awake" problem you can use one of methods with 1-2 sec timeout. Its edge case which occurs rarely.