A different way to handle pulse timing

[David Hill]

On 8/5/13 Aug 5, 1: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?
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).
>> 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.
Indeed - and something we document as a "do not do that because it hurts" item. I used this to illustrate the problem. Just like the app writer, we need to make sure we use the user event queue in ways that allows us to handle events in a timely fashion. In some cases - that means we do a lot of work to put computes on a different thread (ie rendering).
>
> Richard


-- 
David Hill <David.Hill at Oracle.com>
Java Embedded Development

Ich weiß nicht.
-- an unknown German philosopher