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

[Semyon Sadetsky]

On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:

>>>>>
>>>>> 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?
>>>
>>> If timeout will occur and the test still was not complete, then it 
>>> will be killed, all frames will be closed, the dump of all threads 
>>> will be generated. So the test cannot pass after timeout.
>> I meant when the listener is triggered right before the 2 minutes 
>> timeout, for example in 1 minute 59 seconds. In the current logic the 
>> test passes in this case and no dumps were generated for any thread. 
>> But actually this means an issue because event shouldn't be delayed 
>> for that amount of time or this event is not generated by the test.
>
> If the test will complete successfully before timeout then it will 
> validate the functionality which it was targeted for. The slowness can 
> be from the slow/embedded system, or if the system was overloaded by 
> some other tasks. If the test will fails on such systems by the 
> timeout then the user will be able to tweak it via jtreg parameter.
Anyway 2 minutes seems a very unusual waiting time for the event at any 
circumstances.  Usually, in the client-libs tests after an action is 
triggered, we wait for silence in all event queues plus a small period 
of several hundreds milliseconds. Why in this particular test such huge 
waiting is necessary?
>
>
>>>
>>>>>
>>>>>> 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/20170410/07c637dc/attachment.html>