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.
_______________________________________________
Mailing list: https://launchpad.net/~sikuli-driver
Post to : [email protected]
Unsubscribe : https://launchpad.net/~sikuli-driver
More help : https://help.launchpad.net/ListHelp
