Hello,
could you please review the following fix:
fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
<http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
bug:
https://bugs.openjdk.java.net/browse/JDK-8046495<https://bugs.openjdk.java.net/browse/JDK-8025145>
*Problem:*
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
*Evaluation*:
On Windows we have some algorithm for calculating input event timestamp:
jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
Shortly the timestamp is calculated by the following formula:
when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
Where:
JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
GetTickCount() - Win32 function, current millis from boot time
GetMessageTime() - Win32 function, millis from boot time of the
latest native Message
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).
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.
*Fix*:
Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this
is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent()
The message time offset calculation has been introduced with the fix for
JDK-4434193 <https://bugs.openjdk.java.net/browse/JDK-4434193> 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.
I also didn't find any benefits in using the existing approach:
- all the usages of the TimerHelper are in fact reduced to the mentioned
formula: when = JVM_CurrentTimeMillis() - (GetTickCount() -
GetMessageTime())
- GetMessageTime() always increases (except of the int overflow
moments), thus we couldn't get earlier OS messages after later ones
- TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee
returning the same timestamp across different calls for the same message
time
Thanks!
Anton.
