A different way to handle pulse timing
artem.ananiev at oracle.com
Tue Aug 6 06:13:34 PDT 2013
On 8/5/2013 9:09 PM, Richard Bair wrote:
>> In the past we have seen situations where there are so many tasks
>> on the user event thread, that user response (even on desktop) was
>> not acceptable. Some of these items are getting better as we
>> improve design (ie less redundant layout operations causes by a
>> single change/event).
> Right, but I don't see how that could still happen in this proposal?
> The problem before was the pulse events were handled outside of the
> event queue (as I recall) so that they got higher priority. We got
> rid of the higher priority and starvation ceased. This proposal would
> not reintroduce priorities, so I don't see how you could end up with
> input event starvation again?
Here is that bug:
RT-20656: Pending requests from Application.invokeLater can cause input
It is indeed fixed, but the fix was to make sure we always have a window
to dispatch input events (sometimes, very small, but still). Higher
priority for user/application runnables is still there.
>> BTW - it is very easy to write a "bad" app which will demonstrate
>> the problem. As a thought example - if on a button click, you
>> calculate PI to the nth digit before updating your text field - and
>> you do it in the event callback - you are stalling the user event
>> thread. Add in enough computes and you get an very unresponsive
>> app. Instead of computes, you can just call sleep to see the
>> problem too :-)
> But this is the case today as well.
More information about the openjfx-dev