A different way to handle pulse timing

[David Hill]

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.Hill at 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.Hill at 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.Hill at 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