<AWT Dev> [9] Review request for 8046495: KeyEvent can not be accepted in quick mouse clicking

[anton nashatyrev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140701/2fc1e846/attachment.html>