<AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

[Semyon Sadetsky]

On 04/07/2017 04:42 AM, Sergey Bylokhov wrote:

>
>> 6 апр. 2017 г., в 23:26, Semyon Sadetsky <semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com>> написал(а):
>>
>> On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:
>>>>
>>>> Sergey, could you replace CountDownLatch::await() call with its 
>>>> limited wait time analog. If the test fails it blocks execution for 
>>>> 2 minutes in the current version.
>>>>
>>> 2 minutes is a default time out for jtreg tests, if something goes 
>>> wrong like something hangs, then we wait 2 minutes and interrupt the 
>>> test.
>>> After interruption the jtreg will generate the dump for all threads 
>>> which can be useful to check why the event was not generated by the 
>>> robot.
>> You are able to print out this useful information after timeout in 
>> the catch block.
>
> We already have a mechanism which kills the tests after timeout, we 
> also have a default timeout of 2 minutes.
> I am not sure how to get dump of all threads from the catch block.
But shouldn't the time frame when a mouse click may come be limited? 
Will it be correct when the click triggered after 2 minutes delay makes 
the test passed anyway?
>
>> I would prefer to avoid any infinite waiting because if the listener 
>> is not triggered in several second it will unlikely be triggered at 
>> all. But if a number of such tests fails for some reason the 
>> execution time becomes so long that the test report cannot be 
>> obtained in a reasonable time.
>>>
>>>>
>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>> Here is an updated version:
>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>> It will save 5 sec per test, so probably the simpler .00 version 
>>>>> can be reevaluated.
>>>>>
>>>>>>
>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which 
>>>>>>>> is likely why the test had
>>>>>>>> @requires (os.family == "windows") even if it was not the right 
>>>>>>>> name. Now you are running unconditionally with those properties 
>>>>>>>> on all platforms which seems to be a waste of time.
>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 
>>>>>>> modes out of 5 is noop. But I do not like to exclude them, 
>>>>>>> instead I would like to fuzz the tests by supported/unsupported 
>>>>>>> properties, in the same way as 2d-tests are executed using 
>>>>>>> different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>>>   The test can be separated on two tests: one is Windows specific 
>>>>>> and another is general.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello,
>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>
>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the «Dsun.java2d.win.uiScale» option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>
>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>
>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>
>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>>>>>> I’ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>
>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170407/7a72f406/attachment.html>