A different way to handle pulse timing

[Artem Ananiev]

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
>