Added requestAnimationFrame support

[plehegar]

No description provided.

[travisleithead]

Let's use Bikeshed's markdown minimal syntax for new content:

• No need for <p>, just separate paragraphs by a newline
• Lists use numbers (1., 2., etc.) with proper intentation as seen above (line 982 for example).

Additionally,

1. Let's drop the 'algorithm' attribute below. Seems like a nice idea, but has no bearing on our spec processing
2. <code>Document</code> and <code>Window</code> should be {{Document}} and {{Window}} respectively, so that they link-up.

[adanilo]

LGTM

[blurbusters]

Reference: #159 and #375 (both slightly different, for good reason)

Glad to hear requestAnimationFrame() is being restored to HTML 5.1 (unless an alternate replacement, such as #375, occurs). This is because requestAnimationFrame() has ended up becoming the defacto way of synchronize animations to refresh rate (for non-WebGL animations) and there are no alternative APIs that can do the same thing.

Some suggestions:

-- Strengthen requestAnimationFrame() requirement to make it mandatory to synchronize to refresh rate (end of section 5) for more consistent behavior across systems. Right now it's only a recommendation, it should be REQUIRED instead. Most web browsers do, with the surprising sole exception of Microsoft Edge (hardcoded to 60, even with non-60Hz displays) which is worse than Internet Explorer -- See http://www.testufo.com/browser.html

-- Alternative: Add a flag to indicate whether rAF() synchronizes to VSYNC (syncs to refresh rate) -- such as doesRAFsyncToRefreshRate() = true|false
As it stands now, loading benchmark at www.testufo.com always shows 60Hz in Microsoft Edge browser even on non-60Hz screens -- while IE/FireFox/Chrome/Safari/Opera reports the correct refresh rate 50Hz, 75Hz, 90Hz (Oculus Rift/HTC Vive), 120Hz, 144Hz, etc -- this is achieved by counting requestAnimationFrame() callbacks per second.

-- #159 and #375 has many useful comments worth reading; in order to understand the importance of requestAnimationFrame() as the smoothest possible way of animations in HTML5 thanks to its ability to synchronize to VSYNC.

A very good test for requestAnimationFrame() precision across several browsers:
-- www.testufo.com/animation-time-graph

A very good comparision between web browser accuracy of requestAnimationFrame()
-- www.blurbusters.com/blur-busters-120hz-web-browser-tests/

Right now, this screen does user-agent detection out of necessity (since there's no "doesRAFsyncToRefreshRate() API)
-- www.testufo.com/browser.html

Alternatively, another idea is making it mandatory -- that browsers MUST sync rAF() to refresh rate, by making it a requirement rather than a recommendation.

Knowing whether VSYNC is supported -- is very important for precision animations (e.g. www.testufo.com/eyetracking ...) which works on roughly 80-90% of browsers (including iPhones and iPads). This optical illusion animation massively malfunctions in Microsoft Edge on a 75Hz display (or any non-60Hz-multiple display) because it doesnn't synchronize animations to refresh rate.

Many HTML5 games works best with precision stutter-free animations (example: perfectly smooth zero-stutter animation similar to www.testufo.com/photo ...) which is only possible when requestAnimationFrame() synchronizes successfully to the refresh rate, e.g. games that uses lots of large-area smooth-scrolling or panning effects. Fluidity of games varies a lot between browsers and platforms. Knowing whether the game synchronizes to refresh rate, can be quite useful.

[blurbusters]

Update....I had the opportunity to look at the requestAnimationFrame() (aka "rAF") updates to HTML 5.1 ... some good, some bad:

Two things. One good, one bad:

The Logic -- LGTM
The Processing Model -- needs improvement

7.8 requestAnimationFrame API:
https://w3c.github.io/html/webappapis.html#animation-frames
-- This is where requestAnimationFrame() is mentioned

7.1.4.2 Processing Model:
https://w3c.github.io/html/webappapis.html#event-loops-processing-model
-- This is where 60Hz is mentioned, a magic number, instead of recommended phrase "display refresh rate".

For the purposes of what I'm writing -- terminologies & semantics -- "Synchronizing to VSYNC" is usually synonymous to "Synchronizing to the refresh rate of the current monitor the browser window is on" -- and the old W3C rAF() standard described synchronization needs much better.

While the logic LGTM, the processing model is not as good from an animation fluidity perspective, and from a standardization perspective given the magic numbers included in that paragraph. With PAL TV 50Hz, movies updated at 24Hz and sometimes 48Hz (HFR movies), VR at 90Hz, gaming at 120Hz or 144Hz, GSYNC, FreeSync, the future 8K 120Hz standard now being developed (this might be the everyday television of 2040s+), GoPro custom frame rates, many newer cheap desktop LCDs able to do 75Hz -- the sole mention of 60Hz to the exclusion of all others -- needs to be addressed.

As evidenced by EDGE's internal synchronization to 60Hz regardless of the actual monitor refresh rate, your new HTML 5.1 specification is actually pandering to the EDGE browser (and its animation flaws). By mentioning "60Hz" instead of "display refresh rate", this sets a dangerous precedent for the minority rather than the majority (see www.testufo.com/browser.html for a list of browsers that properly synchronizes animations to refresh rate).

Let me illustrate the differences in synchronization under the old/new standard.

---

The old requestAnimationFrame() standard www.w3.org/TR/html51/ says:

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

The new HTML5.1 standard says this:

Whether a top-level browsing context would benefit from having its rendering updated depends on various factors, such as the update frequency. For example, if the browser is attempting to achieve a 60 Hz refresh rate, then these steps are only necessary every 60th of a second (about 16.7ms). If the browser finds that a top-level browsing context is not able to sustain this rate, it might drop to a more sustainable 30Hz for that set of Documents, rather than occasionally dropping frames. (This specification does not mandate any particular model for when to update the rendering.) Similarly, if a top-level browsing context is in the background, the user agent might decide to drop that page to a much slower 4Hz, or even less.

From what I see, major problems:

• If you are trying to avoid saying "VSYNC" which can be confusing to many, say "display refresh rate" which is understandable to more people.

• The people who writes web browsers that actually uses specific low-level graphics APIs, will end up asking questons ("Should I synchronize to 60Hz, or should I synchronize to the display's refresh rate?"). It's often easier to understand if you just say "display refresh rate".

• If you are worried about multiple monitor systems (monitors each running at different refresh rates), leave it to implementers to decide. For example, Microsoft Windows automatically synchronizes a window to the refresh rate of the monitor of the biggest overlapping surface area (e.g. if most of the window is overlapping a 120Hz monitor, the graphics updates in Chrome browser refreshes at 120Hz based on the existing Windows APIs used to synchronze update rate to the refresh rate).

• The mention of "16.7ms" suggests the use of a timer rather than using the operating systems' refresh rate synchronization (as recommended by the old W3C standard and implemented by 90% of running browsers). As a side note, updates every 1/60th of a second (16.7ms) does not guarantee fluidity. An update that occurs a tiny fraction of a microsecond too late past the beginng of a VSYNC, can actually cause the update to be delayed until the refresh cycle. System timers to do an animation frequency (like EDGE does) does not always create fluid animations, as trying to synchronize to refresh rate.

• "60Hz" is actually never perfect. Some graphics cards output 59.97Hz, others 59.94Hz, and yet others 60.5Hz. (Google "59Hz" and "59.94Hz vs 60Hz" for examples). It is better to say "display refresh rate" or similar ("refresh rate of the display showing the browser", or other phrases)

• If you want to keep things simplest and leave things out of the specification, do a minor edit and replace all occurances of "60 Hz" to "display refresh rate". Leave interpretation to implementers. It's apparently worked. (90% of browsers -- testufo.com/browser.html ).

• I was going to advocate strengthening the old rAF() standard in terms of refresh rate -- but now I'm trying to battle against weakening (something that has occured with HTML 5.1) -- if you can understand this perspective.

• Yes, there are good reasons to slow down rAF(). This should be mentioend as an "exception situation" after explaining why updates need to synchronize to refresh rate. For example, "when running in the background", or "in a low power battery saver setting, when running a longer battery becomes more important than the quality of animations" (I must add: Most battery powered devices run at 60Hz anyway, and even iOS runs all animations at full rate in battery saver mode)

• Although this is nto mentioned -- Precise timing of delivery of frames to the screen update can be important. The ideal timing right after VSYNC can mean that a large timing error (as long as less than 1/60sec) would still successfully create stutter-free motion because it "rounded off" to the correct refresh cycle, rather than into the wrong refresh cycle. This is borne out in the 60Hz/100Hz/120Hz browser tests: http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/ -- where browsers stuttered more than others whenn rendering took only a millisecond or two longer, while other browsers kept smooth even when 90% almost-too-late for VSYNC (e.g. 90% CPU spent rendering). Meaning, some browser stuttered very badly (even in Desktop High Performance Mode of a 4Ghz desktop) when requestAnimationFrame() took only a few milliseconds (e.g. less than 10-20% CPU) while others kept smooth even all the way to 90% CPU (e.g. 14ms out of 16.7ms spent inside rAF()) ....

• If 60Hz needs to be mentioned, mention it as an example of a refresh rate.
  e.g. "If the display refresh rate is 60Hz, the browser would do a best-effort to update 60 times per second", etc. (or a better wording thereof).

• Fallback framerate behaviours varies between different browsers. If 60Hz is not maintained, 30Hz is a fallback in some browsers. But some browsers use a different algorithm, if 60Hz is not maintained, it simply gradually decreases in rate (e.g. 59, 58, 57, 56...etc). This behaviour observation is found in the 120Hz browser tests. http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/ .... if you zoom the spreadsheet to full screen, you will see what I mean.

• NICE TO HAVE: A way to report to the user whether or not the system is currently synchronizing updates to display refresh rate. This will allow proper validation of motion tests whenever running in full-performance mode in foreground (e.g. scripts can then automatically say that the browser-based motion test is invalid otherwise, or otherwise report to the user that the experience is running sub-optimally).

• NICE TO HAVE: A setting that can enable/disable vsync, and a way to report it to the user. (e.g. similar to Chrome's --disable-gpu-vsync command line option, but as a flag that can turn this on/off). The end result is that repaints will occur as quickly as possible, continuously. Consuming more CPU, but reducing latency (Typically, repaints will occur several times per refresh. And only the latest rendered frame right before VSYNC is the one that gets displayed -- meaning less latency between user input and the rendered image).

  ---

Bottom line, the processing model is worse in HTML 5.1 than in W3C Animation Timing Standard. I feel that magic numbers such as "60 Hz" do not belong in a specification, except as a secondary example (after having already mentioned the primary atomically-important phrase, "display refresh rate"). If this belongs in a separate document, then at least modify "60 Hz" into "display refresh rate", and reword accordingly.

I am an author of two peer-reviewed papers and specification, so I have "specification writing experience" in other spheres:
(A) XEP-0301 specification;
www.xmpp.org/extensions/xep-0301.html
(B) Pursuit camera setups; www.researchgate.net/publication/270396754_Manual_Pursuit_Camera_and_a_Method_of_Verifying_Pursuit_Accuracy
(With NOKIA and NIST.gov as co-authors)
(C) Unpublished, but I am actually one of the people who influenced Palmer Luckey in his testing of low-persistence displays, during his KickStarter days (Palmer is the founder of Oculus), and he was an early user of TestUFO motion tests which he used in development of the Oculus VR goggles.
(D) I am also the inventor of a specific kind of motion test (the same one peer-reviewed by a NOKIA and NIST.gov employee above), which makes me an authoritative expert on fluidity of motion, as well -- located at http://www.blurbusters.com/motion-tests/pursuit-camera

Although the topic matter is unrelated, and I am excessively wordy in these Comments Sections, I know the importance to be careful of wording when writing specifications. I offer to help rewrite a part of Section 7.1.4.2 of the HTML 5.1 specification, hopefully to a similar size (same number of words) while attempting to make it also superior to the paragraph at the end of section 5 of the W3C Animation Timing section. (I know it sometimes takes an hour even to properly do a paragraph!)

No blame -- It is not necessarily anyone's fault -- I realize web standard developers do not have the understanding of certain motion subtleties that, for example, a video game developer or a low-level graphics device driver, needs to have (or programmer of a low-level app screen update routine -- including, say, the programmers of a web browswer). Plainly put, the current wording pertaining to requestAnimationFrame update timing.

I hope my credentials are sufficient enough, to demonstrate, that a very careful, delicate rewording of section 7.1.4.2 is, indeed, definitely needed, to take care to avoid a situation like what has occured with the EDGE browser becoming worse than Internet Explorer in certain eye-pleasing animation fluidity. I love that the EDGE browser has gone into good compliance of the HTML standard, however, the assumed/magicnumber update rate of 60 Hz absolutely needs to be deleted except as a secondary example under the refresh rate heading.

[chaals]

@mdrejhon Can you please open a new issue for this stuff, so we can close #375 and #159 and the bits that are already done? (Or I will do it, but probably not for a week or two)

On a separate note, it sounds like clamping to 60Hz rather than an implementation-determined rate is not really interoperable, in which case we could mark it at risk in the HTML 5.1 Candidate Recommendation - which means it may be removed (otherwise we are stuck with it until we produce HTML 5.2 - and while the first draft of that should be around in days, the 5.1 Recommendation will probably be the latest for a year or so).

[blurbusters]

chaals, I've created #785
Another testing tool, www.vsynctester.com is now available, which should aid in debugging requestAnimationFrame() problems. Click the gear icon for a large cockpit of tweakable settings.