Re: [RequestAnimationFrame] ally: Separate capture & display cycles

> From the perspective of display, and human vision there is a reasonable 
> argument for limiting display updates to 60fps.

> However from a data capture perspective this is totally mistaken.
> Cameras including the 2007 PS3 eye camera offer speeds of 125fps and faster.
> Children and researchers need a simple means to access this data.

> use cases range from a study of horses galloping, or butterfly wings,
> where data may be displayed, at a slower speed than captured, at a later 
> time.

> to eye tracking solutions that use frame rates in the range 30-1300fps
> to process images and estimate accelerations, vectors, and locations.

> Browser based solutions offer opportunities for improving accessibility, 
> whilst broadening participation and developing understanding.

> For this reason I propose that RAF should not be throttled to 60fps, and 
> that the display cycle be a separate process.

First, RAF doesn't say it is throttled to 60fps. It is the accepted fps
for web performance nowadays but RAF only indicates a signal to the user
agent that a script-based animation needs to be resampled. It doesn't
impose a particular framerate. Having said that and as far as I
understand it, it wouldn't make any sense for the user agent to invoke
RAF more than 60 times per second if the display is only capable of
60Hz. You might have a nice camera to capture your images but that won't
give you automatically a nice display to watch them...

Philippe

Received on Tuesday, 9 April 2013 20:17:33 UTC