I'm not sure you can ever achieve 'ideal' results when it comes to the interaction between requestAnimationFrame and vsync. requestAnimationFrame is fundamentally flawed for combining low latency with tearing-free presentation because it conceptually ties updating, rendering and presentation all into a single callback.
For the average case, though, just getting rAF fired immediately after the previous frame is presented (which should line up with vsync, I think?) will probably suffice - gives you a fairly precise 60hz timer that aligns well with GPU availability so that you know your first call to canvas/webgl isn't going to stall for 5ms waiting on the gpu, and the regularity ensures you don't see strange discontinuities. Goals like trying to reduce effective latency by waiting until N ms before vsync in order to do work are great, but the rAF model needs to be fixed (or replaced) before it's a realistic choice, IMO. Approaches based on estimating frame time predicting the best time to schedule a frame are way too fragile on a modern desktop: available CPU/GPU resources vary, the CPU/GPU clock switch based on various constraints, the machine might go onto/off of battery at any time, and scene complexity is not constant in almost any modern game. Given detailed knowledge of vsync timing and precision scheduling, I think tucking incremental GCs into the gap between rAF callbacks and vsync would do a lot more for the experience of web games than trying to reduce best-case latency by 5ms. A lot of modern PC and console games are okay with 48ms+ of presentation latency because players adapt to it, as long as game logic runs regularly and things like netcode/input aren't unnecessarily buffered. I wrote a random screed on some of these problems with suggestions for how to address them a while ago; some of it may not be accurate anymore but it is aimed at explaining how this use case affects games in particular. (I won't claim to know how things like streaming video fit into this model; I suspect the needs are dramatically different.) https://docs.google.com/document/d/1Z9pqFkumi8UTOmKhvHQoXNCzvtAe1Pn0B2LQgFNrSBY/edit?usp=sharing More precisely, roc's proposal looks solid to me, and other than the stuff I mentioned my only concern is the note that the rAF rate will randomly drop to integer multiples of vsync (30hz, 15hz, etc). Chrome currently has this problem and it creates awful, distracting and unpredictable visual artifacts when it falls into a state of oscillation - bouncing between 30hz and 60hz - or simply runs at 30hz when the machine is not under heavy load. I hope that if possible, making rAF run at something other than 60hz can be avoided. Not having a reliable cross-platform, cross-browser timer to slave game logic to is a real problem, because there aren't presently any good ways to build your own timer. (Having the rendering rate drop to 30hz or 15hz is less problematic, even though it looks gross - that at least does not negatively impact gameplay in any tangible sense.) On Tue, Aug 13, 2013 at 9:35 PM, Robert O'Callahan <rob...@ocallahan.org>wrote: > On Wed, Aug 14, 2013 at 2:30 PM, Jeff Gilbert <jgilb...@mozilla.com> > wrote: > > > 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. > > > > Are you talking about firing requestAnimationFrame for low-latency windows > say halfway through the vblank interval so that input events in the first > half of the interval can be taken into account by a frame composited just > before the end of the interval? > > 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
