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. > > 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. If we treat everything as a low-latency window then we're not anything on a "per-window basis", except of course firing RAFs and compositing, which must be done at per-window or finer granularity. > 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. > 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? Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
