[RequestAnimationFrame] Regarding ISSUE-2, Vsyncing and psychology.

--- COMMENTS ON Timing control for script-based animations, W3C Editor's 
draft June 27, 2011 ---

To the editors.

We are very happy to see this work to enable smooth animation and 
hopefully accurate timing on the world wide web!

This was about time, and this API seems exactly the right way of doing it.

A W3C spec tends to go along unchanged for a long long while, I hope you 
will fill in the remaining blanks with the same care :-)!

I want to voice my 5 cents on 'Issue 2' of the current draft, so we and 
others can build high-quality online psychological experiments, and also 
just enjoy animation like Walt Disney would have done it.


CONCERNING "ISSUE-2: CALLBACK TIME PARAMETER NEEDS DEFINITION"

In the description-page of the issue, the "time of the next display 
refresh" is considered as one of the options for the meaning for the 
callback time-parameter.

I hope this will be chosen, and will be a 'SHOULD'.

This is why:


1. FLUENCY OF ANIMATION: TIME-PARAMETER NEEDS TO HAVE A CONSTANT OFFSET 
TO THE VBLANK

For smooth animation the callback time-parameter needs to have a 
constant offset to the next VBlank time.
Else one will perceive jitter, judder, and temporal aliasing.

(Only Microsoft IE with its VBlank alignment of setTimeout() currently 
fully satisfies this requirement. In a 'creative' way, but it works! :-) )


2. A WAY IS NEEDED TO DETERMINE VBLANK TIME

In some scenarios a way to predict the next or know a previous VBlank 
time is needed.

Our own use-case is that we're building a really good tool for online 
psychological experiments, many of those involve reaction-times. There's 
tremendous growth of interest in crowd-sourcing experiments, from 
researchers in neuro-science, human-behaviour and psychology. Many of 
those experiments are based on measuring reaction-times in different 
conditions, which can give a lot of information about how the brain is 
doing things. For example: Retrieving from long term memory is slower 
than from short-term memory. (We're just like computers :-) And you're 
likely to react quicker on something you like.
The differences in time are subtle, many measurements are needed even in 
ideal hard/software conditions, and there's enough variance in I/O 
already. If we have VBlank time we think it's doable.

Knowing the VBlank time decreases the variance in our measurements with, 
say 16.7 ms, which really matters.

But other areas having benefit are thinkable (broadcast industry 
perhaps, realtime simulations syncing/networking with other systems / 
devices, I don't know. In a game it might even help out to figure who 
REALLY shot first :-) I remember those kids hated the latency of the 
first LCD's, which were also in the 20 ms range.

It's clean and transparent too. You draw something for a certain point 
in the future that it will be presented. The timestamp tells you that point.

If you can not realize this,
please offer a way to get (measure) ANY timestamp of a vertical blank, 
old or not.
Since the 'period' (as in 'periodic functions') can be measured when the 
'fixed constant offset to VBlank time' requirement (1) is fullfilled, 
the last unknown is the 'phase'. Any VBlank timestamp gives us that phase.
To increase accuracy and simplify programming, the last or coming VBlank 
time would be great.
Yes we can use plugins, but that's a great a burden for mass-acceptation.


MY IMPLEMENTATION IDEAS

Here are some (naive?) ideas about how some things could be realized. 
I'm sure there's a lot going on in browsers and it's all 'a little' more 
complex than stated here, but maybe you like a simple and fresh 
perspective from the outside.

# PREDICTING THE NEXT VBLANK

In our python and java lab-software we use the following simple function 
to predict the next VBlank time based on *any* old measured VBlank 
timestamp, the precise refresh-interval and the current time:

nextVBlankTime =
   anyPreviousVBlankTime +
   ((Math.floor((currentTime - anyPreviousVBlankTime) / refreshInterval) 
+ 1)
     * refreshInterval);

We use a running average of refresh-intervals to keep the prediction as 
accurate as possible, but measuring just a few refresh-intervals would 
suffice too (dropping extremes, which might be caused by dropped frames 
or interruption during the measurement).

# MEASURING VBLANKS

I'd say it's doable, but I haven't looked deep in any browser's code 
yet. In OpenGL it would be setSwapInterval(1), and then after each 
drawing: swapBuffers(); glFinish(); which blocks until the VBlank. Yes 
it blocks, but a (higher-priority) wait-thread and maybe doing detection 
in a different OpenGL context might keep performance impact on the 
browser low? Windows DirectX and Mac CoreVideo have dedicated functions 
too, which might be better in some situations. (e.g. Intel GMA failed 
using the mentioned OpenGL method with us).


So far my wishlist.

Thank you for getting all together on this great spec, and hope your 
developers can make it true.

I'm already looking forward to see web-silky-smooth :-)


Jan Linnebank

At UvA NeuroTest B.V.

Received on Friday, 1 July 2011 05:32:56 UTC