[Dojo-checkins] [dojo] #9429: doh.robot.mouseMove firing rate

[dojo]

#9429: doh.robot.mouseMove firing rate
---------------------------+------------------------------------------------
 Reporter:  liucougar      |        Owner:  liucougar
     Type:  enhancement    |       Status:  reopened 
 Priority:  normal         |    Milestone:  1.4      
Component:  TestFramework  |      Version:  1.3.0    
 Severity:  normal         |   Resolution:           
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by bill):

 * cc: haysmark (added)
  * status:  closed => reopened
  * resolution:  fixed =>


Old description:

> While trying to run dojox.sketch functional test
> (dojox/sketch/tests/test_full.html, click the FT button after robot is
> initialized) in IE7 within a virtualbox environment (guest is windows
> xp, host is windows xp), I noticed that it is very slow when the mouse
> is moved on the drawing area.
>
> Looking at DOHRobot.java, in MouseMoveThread::run(), there are following
> lines:
>
> robot.setAutoDelay(Math.max(duration/100,1));
> robot.mouseMove(x1, y1);
> int d = 100;
>
> d is basically how many mouse move events it should generate. I think
> it would be better if that is not hardcoded here. This is my proposed
> patch:
>
> robot.setAutoDelay(1);
> robot.mouseMove(x1, y1);
> int d = duration;
>
> set auto delay to 1 (this is different from the original code if
> duration !=100, but I think this won't affect much). duration will be
> used as how many times mouseMove events are fired. So in dojox.sketch
> test file, I can just specify duration=1, a single mouse event is
> sufficient in this case.
>
> Alternatively, we can introduce another parameter, say firingrate, to
> doh.robot.mouseMove, which is used as d above (instead of duration).
>
> Mark Hays' comment:
> Your approach makes sense. Theoretically it also provides better timing
> for the cases where users move the mouse over a duration that is not a
> multiple of 100ms.

New description:

 While trying to run dojox.sketch functional test
 (dojox/sketch/tests/test_full.html, click the FT button after robot is
 initialized) in IE7 within a virtualbox environment (guest is windows
 xp, host is windows xp), I noticed that it is very slow when the mouse
 is moved on the drawing area.

 Looking at DOHRobot.java, in MouseMoveThread::run(), there are following
 lines:
 {{{
 robot.setAutoDelay(Math.max(duration/100,1));
 robot.mouseMove(x1, y1);
 int d = 100;
 }}}
 d is basically how many mouse move events it should generate. I think
 it would be better if that is not hardcoded here. This is my proposed
 patch:
 {{{
 robot.setAutoDelay(1);
 robot.mouseMove(x1, y1);
 int d = duration;
 }}}
 set auto delay to 1 (this is different from the original code if
 duration !=100, but I think this won't affect much). duration will be
 used as how many times mouseMove events are fired. So in dojox.sketch
 test file, I can just specify duration=1, a single mouse event is
 sufficient in this case.

 Alternatively, we can introduce another parameter, say firingrate, to
 doh.robot.mouseMove, which is used as d above (instead of duration).

 Mark Hays' comment:
 Your approach makes sense. Theoretically it also provides better timing
 for the cases where users move the mouse over a duration that is not a
 multiple of 100ms.

--

Comment:

 This enhancement broke the Tree DnD tests on both FF and IE (on my PC).
 I think browsers can't keep up with 1000 events / sec.  10 events / sec is
 probably a reasonable number.

 Given that other people likely have tests that call mouseMove() I think we
 should fix the test harness so the old tests work, rather than changing
 known tests.

-- 
Ticket URL: <http://bugs.dojotoolkit.org/ticket/9429#comment:4>
dojo <http://dojotoolkit.org/>
The Dojo UI Toolkit