sikuli-driver team mailing list archive

[RaiMan <question195342@xxxxxxxxxxxxxxxxxxxxx>]

Question #195342 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/195342

    Status: Open => Answered

RaiMan proposed the following answer:
I made this test in the IDE.


shouldStop = False
inHandler = 0
modi = KeyModifier.CTRL+KeyModifier.ALT

def handlerx(e):
    global shouldStop
    shouldStop = True
    print "stopping now"
    
def handlery(e):
    global inHandler
    xhk = inHandler+0 # to get a copy
    inHandler += 1
    popup("Hallo from "+str(xhk))
    wait(5)
    print "leaving "+str(xhk)
    inHandler -= 1

Env.addHotkey("x", modi, handlerx)
Env.addHotkey("z", modi, handlery)

while not shouldStop: wait(1)

# to get rid of the hot keys while running in IDE
Env.removeHotkey("x", modi)
Env.removeHotkey("z", modi) # for y on my german keyboard 

# without this, the script will terminate, while handlers still continue
# as long as the JVM is active
while inHandler: wait(1)

print "stopped"

--- I learned the following:
- as long as you run the script in the IDE, the added hotkeys stay active even if the script has terminated. So in IDE it is mandatory to remove them before terminating the script
- every time, a hotkey is pressed, the corresponding handler is started. there is no serialization or communication. If you need something like that (see above: inHandler), you have to implement it via globals or e.g. the Sikuli class Settings.
- the main workflow does not have any information, that a handler is entered (same as for observe()). If you need this, you have to implement it like for serialization.
- main workflow and handlers run independently in parallel

--- cpu consumption
I do not know, how you measure or observe that.
But depending on your kind of observation, there might not be a difference to see, in CPU usage (depends on when and how often it is measured). But the time, the search takes, decreases with the number of pixels to compare. So if you have a search region of 1000x800 (800.000 pixels) and this takes e.g. 1 second for an image of 20x20 (400 pixels) and you search instead in a region of 100x100 (10.000 pixels) the search time should go down to a value below 0.1. But the observed percentage of cpu usage during this time period might even go towards 100% depending on the demand of other running applications.

So I think the problem is not the cpu consumption as such, but the time,
that Sikuli is consuming high % of cpu - and this can be reduced
dramatically with smaller search regions.

might be interesting: bug 988206 and related question.

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