sikuli-driver team mailing list archive

[Jacob Dorman <question191167@xxxxxxxxxxxxxxxxxxxxx>]

New question #191167 on Sikuli:
https://answers.launchpad.net/sikuli/+question/191167

If I using either a Sikuli Observer, or create my own thread that runs an .exists check inside of a region, mouse and keyboard input can be incredibly slow  (choppy jumping and typing) to the point of Sikuli missing clicks when it attempts them.

I'm using a semaphore object to act a queue for when a thread needs mouse/keyboard access.  The semaphore has a ticket capacity of 1, so any other threads that reach a point where they need mouse control will attempt to acquire a ticket, and suspend until the ticket (input control) is granted.

My logic:
    Main thread: Checks various regions in loop, if the pattern exists that it is looking for,  and the thread requires keyboard/mouse control, request a ticket from the semaphore.   After completing its mouse/keyboard usage, returns the ticket to the semaphore to be used by the next thread to request access.
    Observer/secondary thread:  Does the same thing, but only monitors one (different) region at a higher frequency, as it's where the primary work of the program takes place. 

Now regardless of whether I use a separate thread, or use an observer, Sikuli actions run on another thread can be choppy to the point of not working properly (failed clicks being the most common due to mouse "lag" across the screen. 

At first I tried a thread to observe each region, but had this issue.  Now I'm down to the main thread and one observer thread and the issue remains.  I'm not hitting a resource cap or maximum processor usage.  Any idea what could be causing the bottleneck?  

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.