<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello Petr, <br>
    <br>
    <div class="moz-cite-prefix">On 02.07.2014 11:44, Petr Pchelko
      wrote:<br>
    </div>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hello, Anton.
      <div><br>
      </div>
      <div>I'm not sure I have a detailed understanding of what's
        happening. </div>
      <div><br>
      </div>
      <div>Before your fix the timestamp of the event represented the
        time when the event was created, </div>
    </blockquote>
    <br>
    It supposed to represent the time when the event is put by OS to its
    native message queue... But in fact due to timers 'quant effects'
    this time might differ by e.g. 15ms for almost simultaneous events
    (by just comparing their GetMessageTime()).  With adding our
    calculations with different timer types those events might even have
    opposite time order. <br>
    <br>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <div>and now it's the time when it's sent to java.</div>
    </blockquote>
    <br>
    Do we really want to care about what time we would like to use: when
    the message is queued by OS or when the message is dequeued by OS? <br>
    <br>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <div>This might be important if some events cause other events to
        be issued on the java side. </div>
      <div><br>
      </div>
      <div>So suppose the following:</div>
      <div>Toolkit thread: InputEvent#1 created      - timestamp 0</div>
      <div>Toolkit thread: InputEvent#2 created      - timestamp 1</div>
      <div>Toolkit thread: InputEvent#1 sent           - timestamp 2</div>
      <div>EDT:<span class="Apple-tab-span" style="white-space:pre"> </span> 
                     InputEvent#1 dispatched - timestamp 3</div>
      <div>EDT:               FocusEvent  created        - timestamp 4</div>
      <div>Toolkit thread: InputEvent#2 sent           - timestamp 5</div>
      <div><br>
      </div>
      <div>Before you fix we had the following event order:
        InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).</div>
      <div>But after your fix we will have a different order:
        InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).</div>
    </blockquote>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <div>So now we would have troubles, because the Input Event will
        go to the new focused component instead of the old one. </div>
      <div>Do you think that my arguments are correct? I understand that
        the likelihood of such a situation is very low, but for me it
        looks possible? Am I missing something?</div>
    </blockquote>
    <br>
    As mentioned above, the same effect we could easily get with the
    current implementation: the system timestamps may differ up to 15ms
    for almost simultaneous events. But I don't think this have some
    great impact on the scenario you've described. <br>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <div><br>
      </div>
      <div>Another thing I do not understand is why we were used to use
        the complicated formula instead of initializing the msg.time
        field with the JVM current time and using it when sending the
        event?</div>
    </blockquote>
    <br>
    I'm not sure what msg.time you are talking about... As I understood
    the MSG* structure we are creating in native handlers is used for
    referring to an original OS event later. It seems that the time
    field is never used later. Anyways the 'time' field has a concrete
    meaning in Windows docs: number of ms since boot. <br>
    <br>
    It seems that the fix might look risky, but I would like to try
    making the code cleaner first instead of adding additional fuzzy
    logic to it (just for the case I have an initial conservative fix
    which just makes the timestamps sequence non-decreasing). <br>
    <br>
    Do you think we may talk offline to be on the same shape? <br>
    <br>
    Thanks for reviewing!<br>
    Anton.<br>
    <br>
    <blockquote
      cite="mid:B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com"
      type="cite">
      <div>Wouldn't that resolve both your issue and the issue the
        original fix was made for?</div>
      <div><br>
      </div>
      <div>I have a couple of comments about the code, but let's
        postpone that until we decide on the approach.</div>
      <div><br>
      </div>
      <div>Thank you.</div>
      <div>With best regards. Petr.</div>
      <div><br>
      </div>
      <div>
        <div>
          <div>On 01 июля 2014 г., at 21:20, anton nashatyrev <<a
              moz-do-not-send="true"
              href="mailto:anton.nashatyrev@oracle.com">anton.nashatyrev@oracle.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <meta http-equiv="content-type" content="text/html;
              charset=UTF-8">
            <div text="#000000" bgcolor="#FFFFFF"> Hello, <br>
                  could you please review the following fix:<br>
              <br>
              fix: <a moz-do-not-send="true"
                href="http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/">http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/</a><br>
              bug: <a moz-do-not-send="true"
                href="https://bugs.openjdk.java.net/browse/JDK-8046495">https://bugs.openjdk.java.net/browse/JDK-8046495</a><br>
              <br>
                  <b>Problem:</b> <br>
              On Windows the later InputEvent may have earlier timestamp
              (getWhen()), which results in incorrect processing of
              enqueued input events and may also potentially be the
              reason of other artifacts <br>
              <br>
                  <b>Evaluation</b>: <br>
              On Windows we have some algorithm for calculating input
              event timestamp:
              jdk/src/windows/native/sun/windows/awt_Component.cpp:2100<br>
              Shortly the timestamp is calculated by the following
              formula: <br>
                  when = JVM_CurrentTimeMillis() - (GetTickCount() -
              GetMessageTime())<br>
              <br>
              Where: <br>
                JVM_CurrentTimeMillis() - the same as
              System.currentTimeMillis()<br>
                GetTickCount() - Win32 function, current millis from
              boot time<br>
                GetMessageTime() - Win32 function, millis from boot time
              of the latest native Message<br>
              <br>
              In theory the formula looks good: we are trying our best
              to calculate the actual time of the OS message by taking
              the current JVM time (JVM_CurrentTimeMillis) and adjusting
              it with the offset (GetTickCount - GetMessageTime) which
              should indicate how many milliseconds ago from the current
              moment (GetTickCount) the message has been actually issued
              (GetMessageTime).<br>
              In practice due to usage of different system timers by the
              JVM_CurrentTimeMillis and GetTickCount their values are
              not updated synchronously and we may get an earlier
              timestamp for the later event. <br>
              <br>
                  <b>Fix</b>: <br>
              Just to use JVM_CurrentTimeMillis only as events
              timestamp. On Mac this is done in exactly the same way:
              CPlatformResponder.handleMouse/KeyEvent()<br>
              <br>
              The message time offset calculation has been introduced
              with the fix for <a moz-do-not-send="true"
                href="https://bugs.openjdk.java.net/browse/JDK-4434193"
                title="ActionEvents (and other events) need timestamps"><strike>JDK-4434193</strike></a>
              and it seems that the issue has addressed very similar
              problem (At times getWhen()in ActionEvent returns higher
              value than the CurrentSystemTime) which has not been
              completely resolved in fact.<br>
              I also didn't find any benefits in using the existing
              approach: <br>
              - all the usages of the TimerHelper are in fact reduced to
              the mentioned formula: when = JVM_CurrentTimeMillis() -
              (GetTickCount() - GetMessageTime())<br>
              - GetMessageTime() always increases (except of the int
              overflow moments), thus we couldn't get earlier OS
              messages after later ones<br>
              - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't
              guarantee returning the same timestamp across different
              calls for the same message time <br>
              <br>
              Thanks! <br>
              Anton. <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>