SwapBuffers w/SwapInterval(1) can block (or not) whenever it wants to, basically. With SwapInterval(0), I'm not sure we can guarantee we won't have tearing, (except on platforms which don't tear) since we don't really know how long SwapBuffers will take, or when vblank is. (This can probably be done for each platform independently, though)
I'm fairly confident that accumulated RAFs should be triggered after each vblank where we composite. (even probably when we choose not to composite because nothing changed) This allows the users of RAF to get any sort of vsync/no-vsync/sync-control/low-latency that is needed. Bas is also correct about lowering latency by waiting until closer to vblank, and continuing to update the data the compositor renders from, instead of just trying to finish a frame as soon as possible. The proposal reads to me to indicate that low-latency stuff should be handled earlier, but this is only true if you would otherwise miss the vblank window. What Bas described is exactly what we want, to my knowledge. We should definitely prioritize low-latency for the (any?) window which is receiving user input, though. This may mean paradoxically doing the stuff we care less about *before* the stuff we want to be low-latency. (With some padding for safety, of course) -Jeff ----- Original Message ----- From: "Robert O'Callahan" <rob...@ocallahan.org> To: "Bas Schouten" <bschou...@mozilla.com> Cc: "Jeff Muizelaar" <jmuizel...@mozilla.com>, "Vladimir Vukicevic" <vladi...@mozilla.com>, dev-platform@lists.mozilla.org, avih...@yahoo.com Sent: Tuesday, August 13, 2013 6:25:03 PM 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. > 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. 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
