A different way to handle pulse timing

[Richard Bair]

> 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?

> 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