>>> 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? > rendering is "staged" on the event queue (layout, adding the render job to > the render thread). It has been this way for quite a while now. As far as I > remember,( other than paths with "live resize"), we have never had a > mechanism that provided for event priority (at least not on the Linux side > where I tend to live).
This is how I thought it used to be done: we had (still have) a separate glass thread which fires off once ever 16ms or so. We used to take this pulse and handle it at the next available opportunity, which was explicit prioritization. If the pulse handling took longer than 16ms, by the time the pulse ended we'd have another pulse ready to be handled and would starve the queue. Today, we get this event and add it to the event queue, so we are never starving the event queue. In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Thanks Richard
