-
Bug
-
Resolution: Fixed
-
P3
-
7u6
-
None
-
Windows
The root cause of RT-19897 is that, on Windows at least, Runnables posted to the event queue with Application.runLater will be processed at a higher priority than input events. This leads to input event starvation in cases where there is always a pending Runnable on the queue. We have a partial solution to RT-19897 by releasing the barrier early allowing the FX application thread a short window of time to process events before posting the next runnable, but it is fragile.
Additionally, it is the reason we cannot run in full-speed mode without some sort of periodic sleep.
Ideally, runnables and input events would be treated at the same priority and processed in order. At the very least, we need a mechanism to ensure that we don't starve input events.
Additionally, it is the reason we cannot run in full-speed mode without some sort of periodic sleep.
Ideally, runnables and input events would be treated at the same priority and processed in order. At the very least, we need a mechanism to ensure that we don't starve input events.
- blocks
-
JDK-8125853 Delayed event delivery
-
- Resolved
-
- relates to
-
JDK-8123273 GUI easily locked up by excessive GUI updates
-
- Resolved
-
-
JDK-8127081 Responsiveness of UI controls becomes very slow when the window size is very large, and a MediaPlayer is playing at the same time.
-
- Closed
-
-
JDK-8123805 Event locking when SWT-Shell opened via JavaFX
-
- Resolved
-
-
JDK-8093141 HelloComboBox can get stuck.
-
- Closed
-