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

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

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


It sounds like you are describing a quality of implementation issue, not a
spec issue.  Please report the bug to the vendor of the buggy
implementation.  Your proposed text has no normative requirement changes
(i.e. no MUST statements) and isn't a statement of conformance, so I do not
think it would be beneficial.  Text in a spec cannot fix bugs in
implementations.

- James