----- Original Message ----- > From: "Robert O'Callahan" <rob...@ocallahan.org> > To: "Bas Schouten" <bschou...@mozilla.com> > Cc: "Jeff Muizelaar" <jmuizel...@mozilla.com>, > dev-platform@lists.mozilla.org, "Vladimir Vukicevic" > <vladi...@mozilla.com>, avih...@yahoo.com > Sent: Wednesday, August 14, 2013 1:25:03 AM > Subject: Re: vsync proposal > > On Wed, Aug 14, 2013 at 12:13 PM, Bas Schouten <bschou...@mozilla.com>wrote: > > > Since you want composition to occur whenever drawing has occurred, I don't > > really think it should really be what's working on doing any processing for > > the vblank event. The VBlank event should just fire, indiscriminately > > whenever VBlank occurs. I believe we should then consume that event on > > whatever thread is actually doing drawing which might want to know about > > this (a user input thread? the main thread?) and these should then decide > > when to do their drawing and if that warrants a new composition. That way > > you could have, just after vblank, all your scheduled drawing be done, and > > a composition scheduled. But then if right before the next vblank a > > panning/zooming event comes in you can still process that and present a new > > frame to minimize latency (if desired). > > > > That would be good in some ways, but it doesn't handle off-main-thread > animation when the main thread's drawing is late (e.g. because the main > thread is stuck doing something else). For that we must have a way to > control composition based on VBlank signals that doesn't involve the main > thread.
Right, I'm saying you dispatch the VBlank events to any thread that needs to do things on VBlank, so you might -also- dispatch it to any thread that controls async animations (even if this is the compositor thread), I simply wouldn't put this 'in between' the VBlank event and the main thread. > > What you could also do is do all your main thread drawing and processing > > rAF things just after vblank, since they'll likely be somewhat time > > consuming, and schedule your composition only for example 5 ms before > > VBlank (since that will likely be fast). You could then make some > > adjustments to the layer tree through the APZC for user input later in the > > frame, and still have those taken into account for composition, that would > > give you a minimal input latency without wasted work and still starting the > > content drawing required as early as possible giving it maximum opportunity > > to make the next frame. This may be a little bit too complicated for a > > first implementation, but I wanted to throw it out there as a suggestion as > > well. > > > > That sounds exactly like the "Lowering Latency" extension in the wiki page > (if we treat everything as a "low latency" window). If you agree, maybe we > should just do this. Not completely, first of all I don't think as suggested in the proposal this should be done on a per-window basis. Nor do I really think in general where we tick the refreshdriver should be affected here. I think we simply want this low-latency composition to be directly event driven (i.e. user-input). I also think the 'vblank event handler' should be completely left out of of this, except maybe to schedule the timing for the composition (since this composition will be driven by other events). Best regards, Bas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
