[RequestAnimationFrame] Extensive tests with 120Hz monitors. Successful in 4 out of 5 browsers. Proposed W3C draft change.

I wanted to inform W3C about my extensive requestAnimationFrame() tests at
60Hz, 100Hz, and 120Hz:
GRAPH:
http://www.blurbusters.com/wp-content/uploads/2013/08/InternetExplorerRequestAnimationFrameBenchmarks.png
(This is the most important link!)

I'd like to participate in Internet standardization about
requestAnimationFrame() to ensure web's future compatibility for 120fps on
120Hz computer monitors.
*I have a proposed modification to Section 5 of W3C Working Draft "Timing
control for script-based animations" at the bottom of this message.  We
found 4 out of 5 browsers stuck to a requestAnimationFrame() standard
successfully animating at 120fps @ 120Hz, with 1 out of 5 browsers
divergingfrom a widely-implemented requestAnimationFrame behavior due
to an
arbitrary hard-coded framerate limiter, found in discoveries during several
days of nonstop testing.*



INTRODUCTION
============
-- I am the author of some Internet Standards.  I'm the author of
http://www.xmpp.org/extensions/xep-0301.html which is an extensive Internet
Standard document that I spent more than 500 hours on over the last two
years; so I have some standards experience.
-- I'm the operator of a popular 120Hz web portal at blurbusters.com where
about 50% of my web visitors are 120Hz users (high-end video game users
using 120Hz computer monitors).  I'm known in many forums as one of the
leading 120Hz gaming experts.
-- I created several browser-based motion tests at testufo.com including
web animation performance profiling.


W3C STANDARD FOR REFRESH-SYNCHRONIZED requestAnimationFrame()
=========================================================
Recently, W3C recommended that requestAnimationFrame() is synchronized to
the monitor's refresh. This was a very good move to allow very fluid
animations in web browsers.

End of Section 5 of http://www.w3.org/TR/animation-timing/
>>"The expectation is that the user agent will run tasks from the animation
task source at at a regular interval matching the display's refresh rate.
Running tasks at a lower rate can result in animations not appearing
smooth. Running tasks at a higher rate can cause extra computation to occur
without a user-visible benefit."

As creator of TestUFO Motion Tests, I have done extensive browser fluidity
tests.  I am pleased to announce that for 60Hz monitors, all 5 major
browsers now follow this recommendation for foreground animations on a
lightly loaded system, with flawless 60fps@60Hz animations synchronized to
VSYNC, provided processing time inside requestAnimationFrame() is very
small:
- Internet Explorer 10+ (Windows)
- Chrome 16+ (Windows, Mac)
- Safari 6+ (Mac, iOS)
- FireFox 24+ Beta (Windows)
- Opera 15+ (Windows)

The synchronized animations remains true at other refresh rates at 50Hz,
75Hz, 85Hz, 100Hz.  Some problems occur on some platforms (e.g. Chrome on
most Android/Linux platforms does not reliably do VSYNC yet).  Only one
unexpected uncontrollable divergence occurred in one browser at 120Hz (not
for performance reasons); explained below.


TEST CONFIGURATION FOR BROWSER 120Hz TESTS
==========================================
Test System is:
- Intel i7-3770K CPU + nVidia Geforce GTX680 (mid-range gaming system)
- Windows 8
- Single monitor mode (to avoid Windows composition synchronization issues).
- ASUS VG278H monitor running at 120Hz.
(See blurbusters.com/faq/120hz-monitors for list of 120Hz computer monitors)

Browser fluidity test suite:
- www.testufo.com/#test=photo
- www.testufo.com/#test=eyetracking
- www.testufo.com/#test=blackframes
- www.testufo.com/#test=blurtrail
- www.testufo.com/#test=animation-time-graph
- www.testufo.com/#test=animation-time-graph&measure=rendering

Testing Note: For the last URL, add &easteregg=1 to end to insert
artificial busywait delays.
A noteworthy feature of TestUFO, is that it is able to detect the refresh
rate of your monitor through JavaScript rAF() counting algorithm whenever
in foreground.  This information is logged into Google Analytics web logs;
revealing 50% of my visitors are using 120Hz computer monitors, due to the
specialization of the website's target audience.


BROWSER TESTS OF 120fps @ 120Hz
=============================
Recently, I did extensive tests with web browser support for fluid
animations on 120Hz monitors.
In GPU-accelerated browsers running on newer nVidia/ATI cards, rendertimes
fell dramatically in all major browsers (by over a 100:1 ratio), to the
point where full-screen 120fps @ 120Hz animations were now practical inside
a web browser (<1ms rendertimes).  Epic's Unreal HTML5 runs WebGL 3D at
120fps@120Hz in FireFox 24+ on an i7 system running a Geforce GTX 680.

-- 120fps VIDEO TEST: Test of a 120fps H.264 video file on nVidia systems
via <VIDEO> element:
www.blurbusters.com/faq/real-time-120fps-video/
....Successful browsers: IE 10+, Chrome 26+, FireFox 24+ Beta
....Failed: Opera 15+ (it stutters extremely badly, as if not properly
synchronized to refresh)
....Note: Certain browsers sometimes require a pause a pause-replay before
video would play smoothly.

-- 120fps ANIMATION TEST: Web performance benchmarks chart at 60Hz, 100Hz
and 120Hz:
www.blurbusters.com/wp-content/uploads/2013/08/InternetExplorerRequestAnimationFrameBenchmarks.png
....Successful: Opera 16+, Chrome 18+, FireFox 24+ (single-monitor mode)
....Failed: IE 10 (hard-coded frame rate limit)
....Test System: Intel i7-3770K CPU + nVidia Geforce GTX680 (mid-range
gaming system)
....Note: 120fps worked on Mac in Safari in a separate, independent test.
(120Hz on a Mac is not officially supported by Apple).


TESTING SUMMARY
================
- 120fps @ 120Hz requestAnimationFrame() is practical and in wide use.
- 120fps HTML5 videos work already in some browsers (IE10+, Chrome, and
FireFox)
- 120 Hz users are typically performance-minded people, and typically
running fast systems.
- Battery powered systems typically run at low refresh rates (50Hz and 60Hz)
- Zero impact on power consumption for 60Hz systems;
- I have a Kill-A-Watt(TM) electric power consumption meter.  In tests, a
browser's support for 120Hz animations had zero effect on the browser's
power consumption during 60Hz mode.  The CPU % utilization is unchanged.


BROWSERS WITH ARBITRARY FRAME RATE CAP
=======================================
It was discovered that one web browser (in this case, Internet Explorer 10)
has an internal frame limit cap of exactly 105 frames per second for
animations via requestAnimationFrame().   It will not animate at more than
half the monitor's refresh rate.  My research leads me to believe might
have been an attempt to save battery power, but there is zero impact for
the majority of systems.  The 120fps animations would only occur on 120Hz
systems (typically power users, high performance systems, intentional
foreground operation, not battery powered systems which typically only 50Hz
or 60Hz).
- This even occurs if I quit all applications and make Internet Explorer
the only window/tab.
- This even occurs when browser consumes less than 1% of CPU.
- There is no way to bypass this, through an undocumented configuration
setting.
- There is no workaround.  Even trying window.setTimeout(callback 1000/120)
only repaints the screen only 60 times per second.
- Strangely, Internet Explorer manages to play 120fps videos at a full 120
frames per second.

Using nVidia's "Custom Resolution" feature (to create custom refresh
rates), I tested incremental refresh rates.  Further testing has shown that
Internet Explorer 10 suddenly halves the framerate when running at 106Hz:
Running at 102Hz -- requestAnimationFrame() callback 102 times/sec
Running at 103Hz -- requestAnimationFrame() callback 103 times/sec
Running at 104Hz -- requestAnimationFrame() callback 104 times/sec
Running at 105Hz -- requestAnimationFrame() callback 105 times/sec
Running at 106Hz -- requestAnimationFrame() callback 53 times/sec
Running at 107Hz -- requestAnimationFrame() callback 53.5 times/sec
Running at 108Hz -- requestAnimationFrame() callback 54 times/sec

-- This is reliably repeatable on multiple systems, at multiple different
performance levels.  This specific browser (Internet Explorer 10) appears
to have an arbitrary frame-rate cap of exactly 105 frames per second,
either directly (i.e. via a frames-per-second limit) or indirectly (i.e.
via an arbitrary milliseconds-per-refresh value).
-- This occurs even with a single browser window, foreground, no background
apps, in a very tiny 8x8 pixel blank <canvas> (fill rectangle only), with
the animation taking only microseconds to complete (Javascript
high-precision timer delta of 0 for "performance.now", or with several 0's
after the decimal point -- mere microseconds). This would suggest that
performance is not at fault, and that the animation rate is arbitrarily
throttled.


USE CASES FOR 120fps @ 120Hz
==========================
Historically, people who have never seen a 120Hz monitor have said there
was no benefit to the human eye, but scientifically, in a blind test, 88%
of gamers were able to identify 120Hz over 60Hz:
http://techreport.com/news/25051/blind-test-suggests-gamers-overwhelmingly-prefer-120hz-refresh-rates

This is a scientific test of human being able to see 120Hz.  In addition,
several parties such as John Carmack and Michael Abrash has discussed the
topic.

(1) HTML5 games.
Unreal's HTML5 WebGL at http://www.unrealengine.com/html5/ uses
requestAnimationFrame() for the WebGL frames, and runs framerates
synchronized to refresh rates in the new FireFox 24+ beta, even at a full
120 frames per second, full-screen, on a mid-range 120Hz gaming system
(older i7 CPU, a 1-year-old midrange Geforce 600-series).   Newer HTML5
games are designed to automatically adapt to any refresh rate.  Such games
should be permitted to run at full framerates in foreground, if sufficient
system performance is available.

(2) Smooth scrolling animations.
Animations such as www.testufo.com/#test=photo look twice as smooth on a
120Hz monitor as a 60Hz monitor.
The reason it looks twice as smooth is well-explained by a Michael Abrash
article at:
http://blogs.valvesoftware.com/abrash/down-the-vr-rabbit-hole-fixing-judder/


(3) 120fps videos in HTML5 <VIDEO>
Modern desktop computers with nVidia/ATI GPU's are apparently able to play
H.264 bitstreams at 120 frames per second today.
http://www.blurbusters.com/faq/real-time-120fps-video/
It is possible to convert slow-motion 120fps videos (from Samsung Galaxy S4
smartphones, Casio cameras, GoPro cameras, and the upcoming new iPhone with
120fps slo-mo feature), into videos that play at real-time 120fps speeds.
 Some video cameras, such as RED Cinema, have a native 120fps feature, and
some film directors such as Douglas Trumball is looking to make a HFR
120fps film in the future (High Frame Rate).

(4) Detect the refresh rate of a web visitor.
Ever since W3C recommended synchronizing requestAnimationFrame() to the
refresh rate, it became possible to reliably detect the refresh rate of a
web visitor (i.e. Over 90%+ of the time, if a 120Hz web visitor visits in
Chrome).  An example web site is testufo.com <http://www.testufo.com/> which
all 5 web browsers can usually detect the refresh rate of a web visitor on
single-monitor systems. (Except Internet Explorer browser above 105Hz,
which is detected at half refresh rate, due to the requestAnimationFrame()
limiter)
There are useful use cases for detecting the refresh rate of a web visitor:
....Detecting refresh rate can allow precise synchronized scientific motion
tests (such as the several tests found at TestUFO ...)
....Detecting a 120Hz visitor can automatically prompt the user the choice
of a 120fps video. (typically, 120Hz visitors are already using GPU's
already capable of decoding H.264 120fps).
....I am in talks with a video playback website that wants to host 120fps
HFR real-time-playback videos.
This would be more pratical if the 120Hz monitor could be detected before
giving the user the choice to play the true realtime 120fps video file.  It
works in Chrome and FireFox, but even though IE10 can play 120fps video
files, it's not possible to detect if the user is running on a 120Hz
monitor, due to Internet Explorer's internal 105fps framerate cap for
requestAnimationFrame()

(5) Teaching People -- Vision Science Education

 One can educate people about motion blur using TestUFO links:
"Here's an educational demo of eye-tracking motion blur at
http://www.testufo.com/#test=eyetracking "

But it does not look correct unless framerate=Hz, so I have to tell people:
"Here's an educational demo of eye-tracking motion blur at
http://www.testufo.com/#test=eyetracking ... Please use Chrome to view this
animation, IE10 does not support 120Hz"
Other people (other than myself) are already recommending people away from
Internet Explorer because of TestUFO not looking correct in IE10 on 120Hz
monitors. (I can provide multiple links on request)


RECOMMENDED CHANGE TO W3C STANDARD
=====================================
Frame rate caps hurt the usability of web browsers on 120Hz monitors, as
shown by an exact framerate cap found in one browser during my testing.
 Fortunately, most web browsers are do not have caps and are compliant with
this proposed change.  Since one browser was found to have arbitrary frame
rate cap, we would like to improve web standardization by proposing an
addendum to the end of Section 5 of http://www.w3.org/TR/animation-timing/ as
follows:

*CHANGE:*
*>>"The expectation is that the user agent will run tasks from the
animation task source at at a regular interval matching the display's
refresh rate. Running tasks at a lower rate can result in animations not
appearing smooth. Running tasks at a higher rate can cause extra
computation to occur without a user-visible benefit."
*
*
*
*INTO:*
*>>"The expectation is that the user agent will run tasks from the
animation task source at at a regular interval matching the display's
refresh rate, including higher refresh rates. Running tasks at a lower rate
can result in animations not appearing smooth. Running tasks at a higher
rate can cause extra computation to occur without a user-visible benefit. *
*
*
*When doing regular intervals matching the display's refresh rate, an
arbitrary frame rate cap must not be implemented, above and beyond the
processing model described above. Given a sufficiently fast system with low
CPU utilization, full framerate animations in foreground shall not be
artificially governed by an unmodifiable frame rate cap value."*


Most web browser vendors already fall in line with this new recommendation
change.
- 4 out of 5 browsers already do 120fps@120Hz, except IE.  Curiously, even
IE can do video at 120fps@120Hz, but not rAF()
- There is no performance impact.   120fps occurs only if performance
allows, and only at 120Hz.
- *There is no efficiency impact or battery power consumption impact for
the above change to the W3C standard*.
(Battery powered systems do not use 120Hz, and even if there was, it would
be high powered power user laptop)