RE: [RequestAnimationFrame] clarification of what 'time' is

Todd,

 

In a nutshell: To eliminate micro-jitter in animations driven by the ‘time’ argument – which are ultimately caused by (well known; see vsynctester.com) delays in invoking the RequestAnimationFrame Processing Model.

 

If inter-frame times are charted, they are not flat (they should be), but jump around, sometimes a lot (by 30% of the frame interval is not uncommon in IE, along with phase shifting).  Even though those rendered frames are then presented to the end user VSYNC aligned (by OS level compositing; an example is DWM in Windows).  Because of this, any time offset from true vsync passed into RequestAnimationFrame only adds unnecessary changes to the location of objects that moved in an animation.

 

In other words, on my system, rendered frames are presented to the screen every 16.721 ms.  My animation code could care less about the 0ms to 4ms internal web browser delay in calling RequestAnimationFrame, because the rendered frames are presented to the screen perfectly aligned on the next vsync interval.  However, if objects in my animation were actually placed in a frame based upon rAF time argument “vsync+jitter”, instead of “vsync+0”, then all objects that moved in that frame will have unnecessary micro-jitter in their placement.

 

For example, what if my time driven animation is: scroll an image by ‘ms’ pixels every rAF, where ‘ms’ is the inter-frame time?  As the spec is written today, the image might very well be scrolled by these pixel amounts:

 

18.021

15.421

19.221

14.221

17.621

15.821

 

even though these rendered frames are then presented to the end user every 16.721 ms.  When clearly, every rAF, the image should be been scrolled by this number of pixels every frame:

 

16.721

16.721

16.721

16.721

16.721

16.721

 

- Jerry

 

PS: The HTML animation example in the spec does not work in IE

 

 

From: Todd Reifsteck [mailto:toddreif@microsoft.com] 
Sent: Wednesday, April 15, 2015 3:18 AM
To: Michael Blain; Jerry Jongerius
Cc: public-web-perf; Justin Rogers; Tobin Titus
Subject: RE: [RequestAnimationFrame] clarification of what 'time' is

 

Jerry/Mike

Could you quickly explain the scenario that this update would improve?

 

Thanks,

Todd

 

On Tue, Apr 14, 2015 at 10:29 AM, Jerry Jongerius <jerryj@duckware.com> wrote:

The 'time' in the rAF callback (Processing Model) should be altered in the
spec to allow (encourage) a web browser to pass the known begin time of the
frame (the vsync timebase) as the 'time', rather than performance.now().