> 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
