<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><p class="">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.</p></div></div></blockquote><div>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.</div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><br class="">
    <div class="moz-cite-prefix">On 04/06/2017 10:57 AM, Sergey Bylokhov
      wrote:<br class="">
    </div>
    <blockquote cite="mid:9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      Here is an updated version:
      <div class=""><a moz-do-not-send="true" href="http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/" class="">http://cr.openjdk.java.net/~serb/8177841/webrev.01/</a></div>
      <div class="">It will save 5 sec per test, so probably the simpler
        .00 version can be reevaluated.<br class="">
        <div class=""><br class="">
          <div class="">
            <blockquote type="cite" class=""><br class="Apple-interchange-newline">
              <div class="">
                <meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
                <div bgcolor="#FFFFFF" text="#000000" class=""> On
                  3/30/2017 10:27 PM, Sergey Bylokhov wrote:<br class="">
                  <blockquote cite="mid:44942D18-F153-45A7-B22D-946A52D008BA@oracle.com" type="cite" class="">
                    <meta http-equiv="Content-Type" content="text/html;
                      charset=utf-8" class="">
                    <div class="">
                      <blockquote type="cite" class="">
                        <div class="">
                          <div bgcolor="#FFFFFF" text="#000000" class="">
                            <pre class=""><span class="changed">sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had </span>
<span class="changed"><span class="changed">@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.
</span></span></pre>
                          </div>
                        </div>
                      </blockquote>
                      <div class="">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.</div>
                    </div>
                  </blockquote>
                    The test can be separated on two tests: one is
                  Windows specific and another is general.<br class="">
                  <br class="">
                    Thanks,<br class="">
                    Alexandr.<br class="">
                  <blockquote cite="mid:44942D18-F153-45A7-B22D-946A52D008BA@oracle.com" type="cite" class="">
                    <div class=""><br class="">
                      <blockquote type="cite" class="">
                        <div bgcolor="#FFFFFF" text="#000000" class="">
                          <br class="">
                          <div class="moz-cite-prefix">On 03/30/2017
                            12:11 PM, Sergey Bylokhov wrote:<br class="">
                          </div>
                          <blockquote cite="mid:694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com" type="cite" class="">
                            <pre class="" wrap="">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: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8177841">https://bugs.openjdk.java.net/browse/JDK-8177841</a>
Webrev can be found at: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00">http://cr.openjdk.java.net/~serb/8177841/webrev.00</a></pre>
                          </blockquote>
                          <br class="">
                        </div>
                      </blockquote>
                    </div>
                    <br class="">
                  </blockquote>
                  <br class="">
                </div>
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
    </blockquote>
    <br class="">
  </div>

</div></blockquote></div><br class=""></body></html>