-
Bug
-
Resolution: Fixed
-
P3
-
7u6
Input event may not be delivered after the current frame has been processed due to the following scenario:
1. Pulse N starts
2. User generates an input event
3. Scene calls mouseHandler.pulse() and schedules a task to run pickProcess
4. Pulse N finishes
5. pickProcess starts
6. the pulse timer expires and schedules a new pulse task
7. pickProcess finishes
8. Pulse N+1 starts
...
The pending input event from 2. will not be delivered after 7. because the pulse task has a higher priority (on Windows at least).
The 3D team has a demo in which pickProcess time is long enough to guarantee that the pulse timer expires at least once.
In that case the pending event may not be delivered at all.
1. Pulse N starts
2. User generates an input event
3. Scene calls mouseHandler.pulse() and schedules a task to run pickProcess
4. Pulse N finishes
5. pickProcess starts
6. the pulse timer expires and schedules a new pulse task
7. pickProcess finishes
8. Pulse N+1 starts
...
The pending input event from 2. will not be delivered after 7. because the pulse task has a higher priority (on Windows at least).
The 3D team has a demo in which pickProcess time is long enough to guarantee that the pulse timer expires at least once.
In that case the pending event may not be delivered at all.
- is blocked by
-
JDK-8127120 Pending requests from Application.invokeLater can cause input event starvation
-
- Closed
-
- relates to
-
JDK-8127322 Exception when a stage is shown in MouseEntered handler
-
- Closed
-
-
JDK-8090492 Mouse event post-processing may do unnecessary work
-
- Open
-