Re: Tweaking default java.awt.Robot settings

["Steve McKayâ" <smckay at google dot com>]

So would you recommend I ignore the test, delete it, add a comment, ...?

--steve

On 9/24/07, David Herron <David.Herron@sun.com> wrote:
> Steve McKayâ wrote:
> > Hi All,
> >
> > I've noticed that at least some of the tests using java.awt.Robot are
> > non-deterministic due to lags is the underlying window system. The
> > java.awt.Component.keyPressTest, for example, fails some of the time
> > (on linux, windows, linux+wine, ...). It looks like enabling
> > autoWaitForIdle (waits for the awt EventQueue to be empty before
> > adding new events to the queue), and setting autoDelay (pauses for an
> > arbitrary period of time) to some magic number of millis well above
> > zero (I use 100) significantly reduces failures. Would anyone object
> > to configuring the Robot with settings like this by default? If no,
> > should the config mechanism be updated to allow tweaking these
> > settings?
> >
> >
>
> I don't know what the classpath implementation of Robot looks like, but
> I do know what Sun's Linux/Unix implementation looks like (having
> written the original version).
>
> Generally Robot has to request the OS or X11 to synthesize the event.
> On Windows there's a direct API call, while on Unix/Linux there is a
> child process which ends up calling XTEST extension methods.  In both
> cases it means there is a nondeterministic delay due to the current
> process scheduling characteristics of the given system.  In other words
> it depends on an external entity, who Robot cannot coerce into
> performing the request within a bounded set of time.
>
> I think that means depending on Robot doing it's thing within a given
> period of time is an invalid test.
>
> Robot does not add events to EventQueue but it requests the OS to
> synthesize an OS-level event.
>
> - David Herron
>
>


-- 
Steve McKay <smckay@google.com>