sikuli-driver team mailing list archive

[diveratis <question225999@xxxxxxxxxxxxxxxxxxxxx>]

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

Hi!

I'm new to Sikuli [and a bit rusty with my Python/Java] and need some assistance with identifying a possible timing issue with my code:
----

from datetime import datetime, timedelta
Settings.ObserveScanRate = 1000.0    #0.001sec resolution on observe()
dataRegion = Region(10,115,550,250)

def eventChange(event):
   event.region.stopObserver()

def logTime(refCapture):
   dataRegion.onChange(250, eventChange)
   click(refCapture)
   startTime = datetime.now()
   dataRegion.observe(5, background=False)
   endTime = datetime.now()
   return endTime-startTime

----
Part of my requirements is to measure the amount of time it takes for the screen to load [or change] after an action is performed. In this case its a mouse click on a button that I've captured in a screenshot and passed as the refCapture argument. Not sure if it's noteworthy to mention, but a large portion of the screen changes occur in under a 1 second timewindow.

#Just an example of calling the function
print("Duration: %s" % (str(logTime(Pattern("screenshot.png").targetOffset(-18,0)))) 

I've noticed while searching the forums here that the observe() function is commonly placed after the onChange call, but I was worried about the time [perhaps 'latency' being a better word choice?]  it would take for the ide to locate the screenshot in the click(refCapture) call. As a result, I thought (but wasn't sure) it would be ideal to place the observe after the click, hoping that by having a high ObserveScanRate I could avoid a race condition between the two. In addition, I'm not sure, but I was led to believe that if i set the Background option to 'False', that my script would pause until a change was observed which would (possibly?) provide a more accurate measurement of the time it took for the screen to change.

The script runs fine visually, but for some reason, the endTime-startTime durations don't align with what I'm seeing on the screen. The duration [endTime-startTime] is sometimes printed before I even notice the screen update which has led me to believe there's something I'm either not getting or there's something wrong with the flow of my logTime function. For example, there are times I can visually see a screen change after 2-3 seconds, but the return statement states that the change has occurred on the order of milliseconds. I've tried placing the observe() call before the click, but as I previously mentioned, the latency of finding the screenshot seems to add additional time to the duration for some steps that normally take <1 second to occur. With the additional time, steps that normally take 0.5 seconds have now been measured at 2.5 seconds, which fails a part of my requirements.

I was wondering if anyone could provide some advice as to how to improve my method of measuring the screen change duration. Could there possibly be some caching going on in Sikuli that I'm not aware of and not wiping? Or am I using a bad approach? Thanks in advance =)

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