On 04/07/2017 04:42 AM, Sergey Bylokhov wrote:
6 апр. 2017 г., в 23:26, Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@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
