A different way to handle pulse timing

[Scott Palmer]

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?


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)
>