- From: Jan Linnebank <jan@linnebank.nl>
- Date: Thu, 30 Jun 2011 23:25:20 +0200
- To: public-web-perf@w3.org
- CC: jaap Murre <jaap@murre.com>
--- 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