----- 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 9:36:15 PM
> Subject: Re: vsync proposal
>
> On Wed, Aug 14, 2013 at 9:39 PM, Bas Schouten <bschou...@mozilla.com> wrote:
>
> > > From: "Robert O'Callahan" <rob...@ocallahan.org>
> > > 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.
> >
>
> OK. Depending on what your exact proposal is, that could cause races
> between layer-tree updates triggered by main-thread requestAnimationFrame
> triggered by a VBlank event, and other compositor-thread activity triggered
> by the same VBlank event.
This can relatively easily solved if we want to, but it does indeed require a
little more care.
> > 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).
>
>
> Simply repainting and recompositing in response to every input event can
> easily lead to overpainting, especially if you include mouse movement.
Possibly, you could limit this to some extent, or more importantly when a user
is actively giving input which affect the layer tree (panning/zooming) it might
be okay to overdraw and consume a little more power and that might actually be
what you want in order to optimize the user experience by minimizing latency.
I'm not sure that's true, but it could very well be.
> > 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).
> >
>
> I'm not sure I understand you correctly.
>
> Can you please produce a detailed proposal?
I'm off today but I'll try my best to have something more concrete by the
beginning of next week.
Bas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
