On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote:
The idea of user event starvation has been mentioned before and has me a little
confused… Why aren't things handled as a simple queue, with no priorities or
anything, so starvation is impossible? Is this something the OS is doing?
There is a "simple" user input queue - the problem is that we dispatch those
arriving events on the user event *thread*, and that thread is used for a lot of thing
other than user input. It is not so much the cost of handling the input, but rather the
cost of handling the actions after input.
As an example, on a mouse click, a control may change - which might cause a
re-layout, which should cause repainting to happen.
Currently, JFX uses a separate "rendering thread" for painting. This is
goodness, especially when you have a GPU. On the user event thread we need to queue up
and then stage the repaint request.
Things are more complicated because many (but not all) painting/window
management tasks need to be single threaded.
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).
Those of us who have been through several iterations of this are suggesting
caution on a rework though :-)
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 :-)
Dave
In terms of rendering fast enough that you can fit things into a vsync period..
that shouldn't be necessary. If you miss one sync period then you should be
finished by the next.. having a strict requirement to fit within a single vsync
period is impractical.
Without access to true sync, a timer would serve the same purpose. Having both
a timer and sync is where things get silly.
Cheers,
Scott
On 2013-08-05, at 9:47 AM, David Hill <david.h...@oracle.com> wrote:
On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote:
as far as I can read it, your idea is to start preparing the next frame right
after synchronization (scenegraph to render tree) is completed for the previous
frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem
with input events starvation. There will be no or very little window, when the
events can be processed on the event thread, because the thread will always be
either busy handling CSS, animations, etc., or blocked waiting for the render
thread to finish rendering.
I think the difference is that I was going to use the vsync as the limiter.
That is, the first time through we do a pulse, then we schedule another pulse,
then we run that other pulse (almost immediately), then we hit the sync point
with the render thread and have to wait for it because it is blocked on vsync.
Meanwhile the user events are being queued up. When we get back from this, the
next pulse is placed on the end of the queue, we process all input events, then
the next pulse.
You are assuming several things here - most of which would not be present on
something like the PI.
* access to vsync
* a fast enough rendering that you can usually fit into a vsync period.
I would be seriously concerned over user event starvation. It would not take
much of a busy set of animations to mean we spin painting a SG that has not
completely caught up with the bindings/and or ignoring the incoming input
events.
--
David Hill <david.h...@oracle.com>
Java Embedded Development
A committee is a cul-de-sac down which ideas are lured and then quietly
strangled.
-- Sir Barnett Cocks (1907 - 1989)
--
David Hill <david.h...@oracle.com>
Java Embedded Development
The radical of one century is the conservative of the next. The radical invents
the views. When he has worn them out the conservative adopts them.
-- Mark Twain
