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

On Wed, Aug 21, 2013 at 7:04 PM, Mark Rejhon <mark@blurbusters.com> wrote:

> 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.
>

If the wording is not acceptable, here's a proposed alternate wording:

*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. *
*
*
*For user agents that choose to do regular intervals typically matching the
display's refresh rate, an arbitrary frame rate cap must not be
implemented, above and beyond the processing model described in this
document. 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."*
*
*
That way, this this leaves the door open to simple agents that decide to
always only do 60fps rAF().
This is only for user agents that are able to synchronize to the monitor
refresh rate.
(i.e. user agents that can synchronize to refresh rate, shouldn't
arbitrarily limit itself above a specific refresh rate.)