Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Everything about displays and monitors. 120Hz, 144Hz, 4K, 1440p, input lag, motion tests & TestUFO, monitor decisions, and more. Questions? Just ask!

Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 20 Apr 2017, 14:04

Unfortunately, the Microsoft EDGE web browser still does not support http://www.testufo.com / http://www.vsynctester.com at anything higher than 60Hz on over 100+ gaming monitors.

Image

EDGE 15 from Windows 10 Creator’s Update still has not fixed this problem, even as gaming monitors begin to proliferate (FreeSync, GSYNC, 120/144/240Hz, etc).

The Chrome & FireFox teams purchased 120Hz+ monitors and fixed their browsers years ago, as confirmed via their BugZilla tracking systems. This is a W3C standard “requestAnimationFrame”.

We wonder why Microsoft has not caught up yet on this W3C standard.

Please SHARE to raise awareness at Microsoft:
BlurBusters.com Page | Share this Facebook Post | Retweet this Tweet
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 20 Apr 2017, 19:55

W3C is working on HTML 5.2 which hopefully should strengthen requestAnimationFrame()

See: https://github.com/w3c/html/issues/785
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 23 Apr 2017, 15:17

I did it.
I submitted a proposed github commit to W3C HTML 5.2 specification.

See newer comments https://github.com/w3c/html/issues/785.

Chief Blur Buster wrote:CHANGE 1 of 2

Another consideration: The wording relating to timing requestAnimationFrame HTML 5.2 Draft 8 feels worse and less consistent/lower-quality (visual animation-wise recommendation of match-to-refreshrate) than current higher-quality browser practice (e.g. current versions of Chrome & FireFox). Even IE/Edge manages to surpass current HTML 5.2 Draft 8 wording, so let's not set the bar that low.

Thus, since this is github, and I apparently am allowed to submit a pull request (that should compel discussion on this :) ...) I'm going to attempt to submit a pull request that changes:

Proposal to CHANGE this (7.1.4.2):

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


Into this:

NOTE: There are many factors that affect the ideal update frequency for the top-level browsing context including performance, power, background operation, quality of user experience, refresh rate of display(s), etc. When in foreground and not constrained by resources (i.e. performance, battery versus mains power, other resource limits), the user agent normally prioritizes for maximum quality of user experience for that set of {{Document}}s by matching update frequency and animation frame callback rate to the current refresh rate of the current display (usually 60Hz, but refresh rate may be higher or lower). When accommodating constraints on resources, the update frequency might automatically run at a lower rate. Also, 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.


Improvements
  • Explains user experience factor sometimes prioritizes over reasons to slow update rate (e.g. no battery limit, no performance limit)
  • Removes "16.7ms" (good) -- to eliminate temptation of wrongly using a timer instead of current mostly-prevailing practice to synchronize to VSYNC or window manager. See earlier post above.
  • "Constraints on resources" is neutral. It can be natural (e.g. insufficient performance) or artificial (e.g. a predefined target on power consumption) or somewhere in between (e.g. a virtual machine with preconfigured parameters). I was very careful to be 100% neutral what "constraints on resources" means; this is left up to developer.
  • Removes well-intentioned but flawed "60-goes-to-30" -- because this isn't one-size-fits-all as sometimes specific apps require gradual degradation in framerate (e.g. 60-59-58-57-etc) -- and also is simultaneously incompatible with upcoming variable refresh rate (GSYNC/FreeSync/VESA Adaptive-Sync/HDMI 2.1 VRR/etc) technologies. See earlier post above.
  • Clearly points out higher-than-60Hz exists -- to eliminate the flawed assumption that Microsoft unfortunately made (IE/Edge issue)
  • Brings back neglected mention about motion quality may be more important than battery in certian circumstances (a mention of motion quality exists in old W3C Animation Timing Standard, but is missing in this document)
  • Discourages cap/limit when there's no constraints necessary.
    Remember: 120 frames per second at www.testufo.com in Chrome on my 5-year-old desktop gaming computer only uses 1% CPU, and less than 10% GPU (in many cases, now less than 2% on newer NVIDIA gaming GPUs)
  • Rewords it in a way that preserves a long-term compatibility path towards future emerging variable refresh rate support such as GSYNC/FreeSync/VESA Adaptive-Sync/HDMI 2.1 VRR/etc -- where display refresh rate dynamically changes. Dozens of times a second -- aka every refresh cycle! Display refresh-rate changes in real-time to match current frame-rate, rather than the traditional vice-versa (traditionally trying to match frame rate to display refresh rate). For over a decade, laptops often temporarily lowers refresh rate on the fly as a power-saving measure, but the new variable refresh rate technologies eliminate visible stutter of framerate changes.
  • Illustrates quality-versus-performance/battery tradeoff choice for useragents
  • Adds inclusion of motion quality (that was mentioned in old W3C Animation Timing standard)
  • Better generalized "resources" language (performance, power consumption goal, battery limit, etc -- but could apply to any resource limitation such as lack of memory, lack of appropriate OS APIs, lack of timer precision, etc. The generic "resources" language is a catchall of any related resource limit a developer may run into.
  • Removes flawed assumption of a single refresh rate. Example is multiple-monitor systems. While this behaviour is not strictly defined, Chrome uses the refresh rate of the monitor that the largest surface area of window is within. (e.g. if 80% of the window is on the 120Hz monitor instead of a second 60Hz monitor, then Chrome automatically uses a 120Hz update frequency on the top-level browser context -- this might be an automatic WDM behavior that Chrome is synchronizing to).
  • Easier to read language (might need a bit of adjustment).

While not perfect wording, and doesn't completely solve #785, I think this wording is a big improvement for many reasons.

@chaals / @siusin -- Can you assign this github issue to me?


.

Chief Blur Buster wrote:CHANGE 2 of 2

Right now, Chrome/FireFox/Opera is 100% compliant already, with only a minor change needed by Microsoft Edge needed (remove the unwanted arbitrary internal cap). Browser vendors have frequently errored into this territory in the last five years, so I've made an additional wording update to make this more airtight, as there are some developers in this world surprised "There are displays above 60Hz?" -- so unfortunately it has to be mentioned.

2nd Change (in addition to earlier change)

CHANGED:
Another example of why a browser might skip updating the rendering is to ensure certain tasks are executed immediately after each other, with only microtask checkpoints interleaved (and without, e.g., animation frame callbacks interleaved). For example, a user agent might wish to coalesce timer callbacks together, with no intermediate rendering updates.


INTO:
Another example of why a browser might skip updating the rendering is to ensure certain tasks are executed immediately after each other, with only microtask checkpoints interleaved (and without, e.g., animation frame callbacks interleaved). For example, a user agent might wish to coalesce callbacks together, with no intermediate rendering updates. However, when are no constraints on resources, there must not be an arbitrary permanent user agent limit on the update rate and animation frame callback rate (i.e., high refresh rate displays and/or low latency applications).


You'll also notice I changed "coalesce timer callbacks together" into "coalesce callbacks together". The requestAnimationFrame() is not a timer per se in the specific case of Chrome and FireFox, they synchronize to an external trigger -- the VSYNC signal has often multiple non-timer methods of detection on multiple different platforms.
  • Callback signal from the OS WDM (window desktop manager)
  • Polling a GPU register (VSYNC true|false) or an API (e.g. RasterStatus.InVBlank)
  • The timing of a return from a flush() call (or other graphics-commit) such as glFlush(). This often pauses until VSYNC, flips a buffer then immediately returns. This gives you the timing of the VSYNC.

While a monitor refresh rate is often sort of like a timer signal -- it's not always a program timer. So I removed the word "timer" (as that word only sometimes true, not always true) while also adding 1 sentence about arbitrary limits.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 23 Apr 2017, 15:19

This is my git commit to my fork of W3C HTML 5.2 standard
https://github.com/mdrejhon/html/commit/bb06ea15f46c7d622ce089e067967380929ddddb

I am attempting to get W3C to approve me as a submitter of changes to the upcoming HTML 5.2 standard, at least for DRAFT 8.

If they do, I will be submitting a pull request -- and if approved -- this could be Blur Buster's first suggested change accepted to W3C, and hopefully should eventually (over the year or two) prevent browser vendors from accidentally making certain kinds of applications impossible in IE/Edge. Many browser developers working on this appropriate critical piece of code, don't even realize there are other refresh rates than 60Hz...

Keep tuned!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby RealNC » 23 Apr 2017, 15:33

One thing worth noting here, is that this issue is not only important due to the "advent of gaming monitors", but also due to OLED monitors most probably entering the mainstream over the next couple of years. Although this is speculation at this moment, it stands to reason that many OLEDs will run at higher than 60Hz rates even in non-gaming models, since the double-image effect of 60Hz double-strobing will probably be seen as a reason to bump OLEDs to 100Hz minimum.

It is very likely that the majority of OLED displays will operate in a strobed mode in order to eliminate pixel retention issues ("burn-in") inherent in current OLED technology.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 1068
Joined: 24 Dec 2013, 18:32

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 23 Apr 2017, 15:39

Not to mention, 90Hz used in several VR goggles, and also the emerging 8K120Hz standard.

P.S. You're welcome to thumbs-up my post at https://github.com/w3c/html/issues/785 -- if you already have a github account.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 23 Apr 2017, 18:21

We're now attempting to catch Microsoft's attention -- gently.

Image

There's hundreds of complaints on other forums, but we seem to be the only ones in the know (since I'm the author of a peer-reviewed conference paper, I'm the author of precision motion tests at TestUFO, and I've got industry standards writing experience), so we're now attempting to participate in the W3C standards-writing process.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 29 Apr 2017, 10:23

Good news -- I'm (Mark Rejhon) an official Invited Expert in W3C Web Platform Working Group!

I'll also be reaching out to Duckware of vsynctester to have him help collaborate on standardizing HTML in wording changes. There's a good little sphere of expertise I can be involved in -- vsync flaws/stutter & motion quality/refresh rate/VRR support in web browsers, using my knowledge posted in github #785.

So far, only wording changes, but over the next few years (HTML 5.3 or HTML 5.4) I'm going to attempt to invite a bunch of other industry experts to join me in trailblaze for a VSYNC API (VSYNC OFF, VRR support, etc) over then next few years to HTML or WebGL.
(see my github #375).
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby Chief Blur Buster » 30 Apr 2017, 13:22

Commit accepted by W3C!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3263
Joined: 05 Dec 2013, 15:44

Re: Microsoft EDGE 15 cannot do 120Hz with www.testufo.com

Postby RealNC » 30 Apr 2017, 13:46

Cheers!
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 1068
Joined: 24 Dec 2013, 18:32

Next

Return to General - Displays, Graphics & More

Who is online

Users browsing this forum: No registered users and 5 guests