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
event starvation
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.
Thanks,
Artem
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.
Richard
