0

I'm trying to speed up an editor for large fortran files, and trying to test my tweaks using Sikuli. The problem is that if I was to type in a file with 20,000 lines, the editor becomes unresponsive. But when I ask Sikuli to type into a 20,000 line file, the editor manages to print out whatever I ask it too (It seems like its hanging but typing invisibly until all the text is pasted). I have tried putting in wait statements in between words to allow reconciling to take place, but nothing seems to be able to slow down the sikuli script. Because of this both tests(One with scalability options turned on, one without) show the same results, but I know this isn't true through manual testing. Any idea as to how I can replicate human typing but through automation, or make Sikuli wait for the text to show up before it continues typing?

Vinay Bangalore Nagaraj
  • 541
  • 2
  • 6
  • 13

2 Answers2

1

The wait function should do exactly what you are requiring.

You probably need to wait 120ms between characters to emulate typing. This would be 100wpm. Look at this Link which describes how to create a random delay time which would emulate the human typing nicely.

spearson
  • 1,016
  • 8
  • 18
  • I'm working on making the editor more responsive. The problem with a random delay time would make it an unfair test. Also, this is tough to describe, but what happens in the untweaked(slower) version of the editor is that it lags in the sense that what I type does not come on to the screen for sometime. A human would wait for the words he types on screen, but sikuli does not. I'm trying to use the Region.onchange function to wait for text to show up on a screen before continuing to type(like a human would) but I can't figure out how to use it in java, there is only documentation for Python. – Vinay Bangalore Nagaraj Dec 12 '12 at 02:56
0

I already answered your question on launchpad/sikuli in a similar way like spearson did above, but now with your additional comment, I finally understand your problem.

Region.onChange():
the observe() feature on the Java level in the current version X-1.0rc3 does not work

But you could build your own observer rather simple:

after a type, where you want to wait for the editor window to update its content

  1. capture the editor region
  2. in a loop check every 0.x secs, wether this image is still found
  3. if the image is no longer found, the editor window has been changed

this is principally, what observe/onChange internally does: with a standard minimum delay of 0.3 seconds (ObserveScanRate) it just compares the screen/region with a given start image.

RaiMan
  • 1,088
  • 8
  • 13