Latency issue when using VNCScreen --- use Settings.MoveMouseDelay=0

Asked by Paul Sommer on 2017-10-20

Hello,

we are exploring the possibilities to use Sikuli for automated test of our application. The problem is that our application is running on CentOS 5.2 and Sikuli isn't. So we installed Sikuli on a separate machine running RedHad. Via VNC we then remotely access our test system. We made some scripts using the IDE and this works fine, but what we see is a latency issue.
example: using the hover command I go n the vnc screen from top left to bottom right and do this many time. When I execute this command we see the cursor moving as expected, although if we look at the screen from our test system the cursor is moving slower. When the test is finished and the Sikuli screen appears again, on the target system the cursor is still moving for a undetermined time. If e.g. the Sikuli script is finished after 10 seconds, on the target system the cursor moves for 20 seconds. You can imaging that this latency can be an issue for large scripts. The VNC connections seems fine. We don't see any latency when operating the target machine via VNC.
Any ideas what could be the cause and how we could further investigate/solve this issue.

Thanks, Paul.

Question information

Language:
English Edit question
Status:
Solved
For:
Sikuli Edit question
Assignee:
No assignee Edit question
Solved by:
RaiMan
Solved:
2017-10-23
Last query:
2017-10-23
Last reply:
2017-10-23
RaiMan (raimund-hocke) said : #1

what Sikuli are you talking about?

Paul Sommer (pauldb138) said : #2

Sikulix IDE 1.1.1 build 2017-03-29-10:41

Paul Sommer (pauldb138) said : #3

Some extra info you may need:
On the target CenOS 5.2 machine a X1VNC 0.9.8 server is running. On the "Sikuli" RedHat 6.8 machine a TigerVNC viewer 1.1.0 is running.

Regards Paul.

Best RaiMan (raimund-hocke) said : #4

try with
Settings.MoveMouseDelay=0

which switches off the mouse move animation (a mouse move is divided into steps towards target with decreasing offsets).

Paul Sommer (pauldb138) said : #5

I'm not sure why the default setting is causing an extra delay on the target, but setting the MoveMouseDelay to 0 seem to solved the problem.

Thanks, Paul.

Paul Sommer (pauldb138) said : #6

Thanks RaiMan, that solved my question.

RaiMan (raimund-hocke) said : #7

The reason is, that the division into move steps is done on the source side, so each step is an extra mouse call to the target, which together with internal latency/waits leads to the effect.

In fact this "nice feature" was introduced by the original developers 6 years ago and allows someone who watches the workflow of his script, to see how the mouse moves. Another effect is, that it usually introduces those short waits (0.5 seconds in the standard), that allow the GUI to complete intermediate adjustments.