A different way to handle pulse timing

David Hill David.Hill at Oracle.com
Mon Aug 5 06:47:55 PDT 2013

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)

More information about the openjfx-dev mailing list