ACTION-27: Fluidity of motion and consistency of framerates

Dear all,

I accepted an action at the Coremob F2F at Facebook to "check whether it is practical to measure consistency of framerate".  I undertook this as I felt that it might be possible to define a standard mechanism for assessing smoothness of animations (such as during a CSS transition).  In short, whilst it's conceivably possible, I feel it is impractical to do so for three broad reasons:

Firstly - Making the measurements:  During the F2F, Jet Villegas of Mozilla explained a number of approaches they used, including adding timing hooks in the browser, and also assessing what is written to the GPU.  Both of these are hard for others to repeat, and the specific timing points are unlikely to be directly applicable to other vendor implementations.  An alternative is to use an external camera pointing at the device under test so that real world rendering can be measured.  This then needs image and motion processing to be applied to assess whether the motion was smooth.  Determining a standard camera and methodology for this test, as well as implementing the image processing would be a challenge.  Furthermore, this would be confounded by environmental and device specific factors (such as response time of the screen) which may appear to penalise a browser on a particular device.

Secondly - Defining standard test cases:  We have found that certain HTML DOM structures are far harder for a browser to process than others, and that the precise way in which DOM manipulations or CSS animations are used impacts on performance.  Determining what is a fair test given real world use cases will be hard.  For example, whilst Opera have proof of concept implementation of pages media [1], on other platforms developers use scripting to build similar behaviour, such as our team's FTScroller [2].  We have found that each platform / browser has a way that enables scrolling and animation to work well, but there's not a magic bullet solution that enables artificial scrolling in all scenarios.  Vendors appear to use different scheduling strategies for concurrent CSS animations and JavaScript executions (eg [3]) for which it's unclear which is 'better'.  As such, determining what is a fair test is hard.

Thirdly - Confounding factors:  Mobile devices receive many interruptions, from system-level garbage collection through to inbound text messages and similar alerts.  The first of these makes the preparation of the device for a predictable test case challenging, whilst defining the acceptable behaviour in the event of certain actions happening will be time-consuming and potentially of minimal value.

Instead, I feel that vendors and the W3 community should observe the polyfills and script libraries that are being constructed to meet the shortfalls of browsers given the behaviours desired by developers, and strive to fill those gaps.  Browser implementations of functionality are likely to be better than those emulated in JavaScript or similar, and that the best short term action should be to help alert vendors to behaviours that result in poor user-experience.



[1] http://dev.opera.com/articles/view/opera-reader-a-new-way-to-read-the-web/
[2] https://github.com/ftlabs/ftscroller
[3] http://jsfiddle.net/v7C4a/


-- 
Dr Robert Shilston [07940 387593 | skype:rtshilston | @rtshilston]
Director, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs]
-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.