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.h...@oracle.com>
Java Embedded Development
Ich weiß nicht.
-- an unknown German philosopher
