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 <[email protected]>
Java Embedded Development
A committee is a cul-de-sac down which ideas are lured and then quietly
strangled.
-- Sir Barnett Cocks (1907 - 1989)
