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 <[email protected]> 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 <[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) >
