Internet Explorer animations FAILS on 120Hz computer monitors (works at 60Hz, 75Hz, 100Hz) - by blurbusters

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 794072 Comments
Status Closed Workarounds
Type Bug Repros 9
Opened 7/15/2013 11:50:12 PM
Access Restriction Public

Description


Animations are not smooth on the new 120Hz computer monitors.
To test on a 120Hz computer monitor, get one of the monitors listed here:
http://www.blurbusters.com/faq/120hz-monitors/

Internet Explorer is unable to run animations at 120 frames per second on new 120Hz computer monitors.   Both Chrome (all versions) and FireFox (pre-beta 24) works.

A good motion animation test website is http://www.testufo.com
See the frame rate counter at the bottom of the page.
Chrome and FireFox (24+) passes this test at all refresh rates.

PASS -- Internet Explorer is able to run at 60fps at 60Hz
PASS -- Internet Explorer is able to run at 75fps at 75Hz
PASS -- Internet Explorer is able to run at 85fps at 85Hz
PASS -- Internet Explorer is able to run at 100fps at 100Hz
FAIL -- Internet Explorer CAN NOT run at 120fps at 120Hz
FAIL -- Internet Explorer CAN NOT run at 144fps at 144Hz

Chrome passes all tests, and FireFox (24+ pre-beta) passes all tests.
Sign in to post a comment.
Posted by Microsoft on 4/4/2016 at 8:53 AM
We've moved! This issue is now being tracked at https://developer.microsoft.com/microsoft-edge/platform/issues/406065/
Posted by Cubellius on 11/28/2014 at 4:19 PM
I tested 133 and 161hz, and they both also seem to work fine in IE version 11.0.9879.0 (Windows 10 Tech Preview).
Posted by blurbusters on 8/12/2014 at 4:36 AM
This appears to be fixed in Internet Explorer 11, as of Version 11.0.9600.17207.

Can you please inform me which minor version of Internet Explorer this is, and what UserAgent string I can use to automatically detect versions of IE that supports 120fps at 120Hz?
Posted by panzeroceania on 2/10/2014 at 11:54 PM
Please look into this matter it will shift my decision to use IE and recommend IE
Posted by Microsoft on 9/16/2013 at 9:39 AM
We are activating this bug in connect to track it for consideration in a future release of IE.
Best regards,
The Internet Explorer Team
Posted by slouprud on 8/6/2013 at 3:50 PM
Please look into this matter it will shift my decision to use IE and recommend IE (many many people take my advice)
Posted by blurbusters on 8/6/2013 at 2:22 PM
Here's a screenshot of my web logs via Google Analytics that shows Blur Busters TestUFO motion tests now has more 120Hz users than 60Hz:
http://www.blurbusters.com/wp-content/uploads/2013/08/LastThreeWeeks-more120than60.png

Top 5 refresh rates in last three weeks:
3706 users of TestUFO using 120Hz
3531 users of TestUFO using 60Hz
536 users of TestUFO using 144Hz
125 users of TestUFO using 75Hz
121 users of TestUFO using 100Hz

This is data only for browsers I can detect refresh rates in. The web logging uses the JavaScript rAF() counting technique. Browsers that does not support VSYNC are ignored (e.g. old FireFox releases)
Posted by blurbusters on 8/6/2013 at 12:33 PM
I have had to warn thousands of readers people away from Internet Explorer because of this;
Here's a Google Search showing my dozens of posts telling people to use Chrome instead of Internet Explorer:
http://goo.gl/Z3Y7GS
I hate doing this, I prefer to say "IE11+ supports 120Hz"
If you can, please fix 120hz for IE11.

I can even show weblogs of over 5,000 visitors who use 120Hz monitors (using a Javascript code that counts rAF() frequency and reports back via Google Analytics).

Several 120Hz use cases below:
__________________________

-- Teaching People -- Vision Science Education
I teach and 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 I now have to also add "...Use Chrome. IE10 doesn't support 120Hz", as shown in the google search of several forum posts: http://goo.gl/Z3Y7GS

___________________________

Here are some useful use cases for 120fps @ 120Hz. Typical 120Hz computer monitor users are the people who already use powerful GPU's which easily renders 120fps in just milliseconds with modern GPU-accelerated web browsers. Here are some use cases:

(1) Perfectly fluid JavaScript-controlled scrolling.
For example, a page-scrolling function may want to scroll a page at the full refresh rate. The effect would be very similiar to this: http://www.testufo.com/#test=framerates-text
Except at 120Hz, this would have half the amount of motion blur (try this in Google Chrome, during 60Hz mode, and 120Hz mode, and you'll understand what I mean).

(2) More fluid photo slideshow transitions
View this: http://www.testufo.com/#test=photo on both 60Hz and 120Hz. A HTML5 app that uses panning transitions, would be able to have far less motion blur than this.

(3) 120fps video using HTML5 <VIDEO>
Many cameras such as the popular GoPro Hero 3 -- the POV camera used in Indy Races, surfing, skydiving, etc, have a high-speed 120fps HDTV mode. This is normally used for slow-motion playback, however it also produces extremely fluid motion when played back in real-time on a 120Hz monitor. It looks absolutely gorgeous. I know of one major video site experimenting with 120fps video (and it already works in at least one browser, since the H.264 / MP4 format supports 120fps video files that are configured to play back in real time instead of slow-motion)

(4) HTML5 gaming applications (e.g. platform scrolling game, space scrolling shoot-em-up)
During horizontal/vertical scrolling motion in games, there would be half as much motion blur on LCD displays, during fast horizontal and vertical scrolling. Scrolling is a very low CPU/GPU activity on modern GPU's taking less than a fraction of millisecond (excluding the time spent drawing new data at the edges of screen).

(5) (Speculative) Future Direct3D JavaScript, if Microsoft has plans.
Right now, your competition FireFox running WebGL and JavaScript is running a full screen 3D video game in FireFox (no plugins) at 120 frames per second on a Geforce GTX 680 -- http://www.unrealengine.com/html5/ (This is not TestUFO tests; but full screen WebGL 3D graphics in 100% pure JavaScript and WebGL with zero plugins, executing the whole scene JavaScript 3D rendering at less than 5 milliseconds per frame at 1920x1080 <canvas> on my computer!). This is some interesting news: http://www.tomshardware.com/news/Epic-Citadel-HTML5-asm.js-UE3-Unreal-Engine,22406.html ...

(6) Teaching People -- Vision Science Education
I teach and 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 work properly 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"
(I've posted this about 30 times already to blogs and discussion forums).
I feel sad that I have to exclude Microsoft, because IE10 is one of my favourite browsers.

Load this link in modern browsers with ATI/nVidia/recent Intel:
http://www.testufo.com/#test=eyetracking
- Chrome @ 60Hz looks correct
- Chrome @ 120Hz looks correct
- Opera15+ @ 60Hz looks correct
- Opera15+ @ 120Hz looks correct
- FireFox24+ @ 60Hz looks correct
- FireFox24+ @ 120Hz looks correct
- InternetExplorer10 @ 60Hz looks correct
- InternetExplorer10 @ 120Hz looks wrong

Educating everyday people about motion blur is harder if one popular browser doesn't support framerate=Hz operation at all refresh rates.

I actually record the requestAnimationFrame() rate to logfiles (number of callbacks per second, average rate over a few seconds, record only the median data), so it's possible to log web visitor's exact refresh rates. From this logged information, I've noticed more than 25% of TestUFO users are using 120Hz computer monitors, since I post my messages in high-end computer forums. I'm educating a specific target audience of many thousands of people (Blur Busters gets 11,000 unique visits per week when excluding spam/bots/crawlers, and 30,000 full pageviews) and I hate to warn my audience against using Internet Explorer.

My JavaScript code at www.testufo.com automatically tells people that their browser is not supported:
-- If the browser is older than a certain version (I have a database of supported browsers)
-- If the browser is performing more than 40% CPU in animations (high likelihood of framerate mismatching refresh rate) I can warn user that their animation might not be accurate.
You can see the Excel spreadsheet screenshot I sent.    e.g. If a browser spends too much time inside requestAnimationFrame() then I can tell them that their system is not fast enough.
-- BUT Javascript can't tell if the user is using a 60Hz monitor or 120Hz monitor in IE10, so I can't successfully detect if the animation probably looks incorrect on their display

Unfortunately in IE10 when I see 60Hz at 1% CPU utilization, I can't tell the difference between a fast computer running 60Hz, or a fast computer running 120Hz. The motion test education fails. So I cannot automatically tell Internet Explorer users that their refresh rate is not supported. 120Hz just looks exactly like 60Hz That's the problem with IE10 right now, as I can't reliably educationally teach my audience about things like motion blur.

I actually already detect slowdowns in framerates or high CPU utilization (using your high-precision "performance.now" that you helped standardize), so TestUFO's logging knows 99% of the time if the framerate is low because of poor performance.

(7) Detect the user's current refresh rate
-- Counting the number of requestAnimationFrames per second and trusting it (in certain popular browsers) to be usually equal the refresh rate, allows optimization of certain animations to be more optimal for specific framerates.
-- Detection of a 120Hz refresh rate can automatically trigger automatic playback of a higher-bandwidth 120fps video via the HTML5 <VIDEO> element
-- Detection of a 120Hz refresh rate can automatically configure certain special features in a web-browser-based game for 120Hz users, such as software-based black frame insertion (e.g. http://www.testufo.com/#test=blackframes ).

For a good test case of refresh rate detection, see http://www.testufo.com at the bottom of the screen. It waits until the loading time settles down (e.g. variances between rAF() becomes consistent) then begins counting (and becomes surprising reliable when the timing deviation between rAf() becomes consistent while in foreground)
Posted by blurbusters on 8/2/2013 at 4:53 PM
[Part 2 of 2]

Scientific Test of 120Hz
Scientific test show that 86% of users overwhelmingly prefer 120Hz:
http://techreport.com/news/25051/blind-test-suggests-gamers-overwhelmingly-prefer-120hz-refresh-rates

Michael Abrash of Valve Software
Michael Abrash of Valve Software talking about 120fps@120Hz, and the benefits of 1000fps@1000Hz:
http://blogs.valvesoftware.com/abrash/down-the-vr-rabbit-hole-fixing-judder

John Carmack of iD Software
John Carmack talking about the benefits of 120Hz in reducing motion blur.
http://www.youtube.com/watch?v=93GwwNLEBFg#at=335

______________

Not just useful mainstr3eam purposes, but Display Researchers including Peter April, Marc Repnow, military vision display researchers, and many others, are very interested in the progress of high-refresh-rate displays

Here's a graph that proves that frame render times is 1 milliseconds and less on recent i3 (and better) systems running at least an ATI, nVidia or at least Intel HD3000 series (and better).
http://www.testufo.com/#test=animation-time-graph&scale=10&ppf=2&measure=rendering
1. Load this link (IE10, Opera15, FireFox 24) on an Intel i3 / i5 / i7 / Sandy / Ivy / etc proccessor
2. Observe that the animated graph itself is animating at just less than 1 millisecond, even in IE10
3. Run this on a 120Hz monitor in 100Hz mode. IE10 still keeps up "perfect smooth"

This additional proof that 120fps is definitely now feasible in modern web browsers. GPU accelerated web browsers managed to fix this -- Even at 100 frames per second, IE10 JavaScript is consuming only 1 millisecond in my full-screen JavaScript animation routines. It animates perfectly, with 100% on-time VSYNC, with no missed frames. A modern ATI or nVidia GPU now easily does frame completions at 120 frames per second for 1920x1080 full-screen.

Users who are using 120Hz are not the users who conserve power. Therefore fixing this won't affect non-120Hz users. The people who buy 120Hz are performance-oriented people. What people do see, is poor visual IE performance and low animation performance. The mainstream people who test battery efficiency of Internet Explorer, are testing on 60Hz displays. Fixing 120Hz WONT interfere with these battery efficiency benchmarks. Laptops typically use 60Hz anyway.

If you have a recent GPU (ATI or nVidia), the good news is that www.testufo.com successfully completes full-screen animations at 120 frames per second at 120Hz. Blur Busters Blog started because of a tweet from John Carmack of iD Software, and Michael Abrash of Valve Software has already complimented on my Blur Busters work.

Instructions:
1. Use a 120Hz monitor from http://www.blurbusters.com/faq/120hz-monitors
2. Use a computer that has either an ATI or nVidia GPU product made in the last 3 years
3. Click http://www.testufo.com/#test=photo
4. This runs perfect full-screen at 120 frames per second at 120Hz on an Intel i3 computer on a mid-range ATI/nVidia/Intel GPU (including Sandy Bridge and Ivy Bridge). Most users who actually get 120Hz, are users who actually upgrade their GPU too as well, even though Intel GPU's are already fast enough too.
Posted by blurbusters on 8/2/2013 at 4:47 PM
Adding useful correspondence between me and Jatinder, who asked me for some use cases:

Here are some useful use cases for 120fps @ 120Hz. Typical 120Hz computer monitor users are the people who already use powerful GPU's which easily renders 120fps in just milliseconds with modern GPU-accelerated web browsers. Here are some use cases:

(1) Perfectly fluid JavaScript-controlled scrolling.
For example, a page-scrolling function may want to scroll a page at the full refresh rate. The effect would be very similiar to this: http://www.testufo.com/#test=framerates-text
Except at 120Hz, this would have half the amount of motion blur (try this in Google Chrome, during 60Hz mode, and 120Hz mode, and you'll understand what I mean).

(2) More fluid photo slideshow transitions
View this: http://www.testufo.com/#test=photo on both 60Hz and 120Hz. A HTML5 app that uses panning transitions, would be able to have far less motion blur than this.

(3) 120fps video using HTML5 <VIDEO>
Many cameras such as the popular GoPro Hero 3 -- the POV camera used in Indy Races, surfing, skydiving, etc, have a high-speed 120fps HDTV mode. This is normally used for slow-motion playback, however it also produces extremely fluid motion when played back in real-time on a 120Hz monitor. It looks absolutely gorgeous. I know of one major video site experimenting with 120fps video (and it already works in at least one browser, since the H.264 / MP4 format supports 120fps video files that are configured to play back in real time instead of slow-motion)

(4) HTML5 gaming applications (e.g. platform scrolling game, space scrolling shoot-em-up)
During horizontal/vertical scrolling motion in games, there would be half as much motion blur on LCD displays, during fast horizontal and vertical scrolling. Scrolling is a very low CPU/GPU activity on modern GPU's taking less than a fraction of millisecond (excluding the time spent drawing new data at the edges of screen).

(5) (Speculative) Future Direct3D JavaScript, if Microsoft has plans.
Right now, your competition FireFox running WebGL and JavaScript is running a full screen 3D video game in FireFox (no plugins) at 120 frames per second on a Geforce GTX 680 -- http://www.unrealengine.com/html5/ (This is not TestUFO tests; but full screen WebGL 3D graphics in 100% pure JavaScript and WebGL with zero plugins, executing the whole scene JavaScript 3D rendering at less than 5 milliseconds per frame at 1920x1080 <canvas> on my computer!). This is some interesting news: http://www.tomshardware.com/news/Epic-Citadel-HTML5-asm.js-UE3-Unreal-Engine,22406.html ...

(6) Teaching People -- Vision Science Education
I teach and 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 work properly 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"
(I've posted this about 30 times already to blogs and discussion forums).
I feel sad that I have to exclude Microsoft, because IE10 is one of my favourite browsers.

Load this link in modern browsers with ATI/nVidia/recent Intel:
http://www.testufo.com/#test=eyetracking
- Chrome @ 60Hz looks correct
- Chrome @ 120Hz looks correct
- Opera15+ @ 60Hz looks correct
- Opera15+ @ 120Hz looks correct
- FireFox24+ @ 60Hz looks correct
- FireFox24+ @ 120Hz looks correct
- InternetExplorer10 @ 60Hz looks correct
- InternetExplorer10 @ 120Hz looks wrong

Educating everyday people about motion blur is harder if one popular browser doesn't support framerate=Hz operation at all refresh rates.

I actually record the requestAnimationFrame() rate to logfiles (number of callbacks per second, average rate over a few seconds, record only the median data), so it's possible to log web visitor's exact refresh rates. From this logged information, I've noticed more than 25% of TestUFO users are using 120Hz computer monitors, since I post my messages in high-end computer forums. I'm educating a specific target audience of many thousands of people (Blur Busters gets 11,000 unique visits per week when excluding spam/bots/crawlers, and 30,000 full pageviews) and I hate to warn my audience against using Internet Explorer.

My JavaScript code at www.testufo.com automatically tells people that their browser is not supported:
-- If the browser is older than a certain version (I have a database of supported browsers)
-- If the browser is performing more than 40% CPU in animations (high likelihood of framerate mismatching refresh rate) I can warn user that their animation might not be accurate.
You can see the Excel spreadsheet screenshot I sent.    e.g. If a browser spends too much time inside requestAnimationFrame() then I can tell them that their system is not fast enough.
-- BUT Javascript can't tell if the user is using a 60Hz monitor or 120Hz monitor in IE10, so I can't successfully detect if the animation probably looks incorrect on their display

Unfortunately in IE10 when I see 60Hz at 1% CPU utilization, I can't tell the difference between a fast computer running 60Hz, or a fast computer running 120Hz. The motion test education fails. So I cannot automatically tell Internet Explorer users that their refresh rate is not supported. 120Hz just looks exactly like 60Hz That's the problem with IE10 right now, as I can't reliably educationally teach my audience about things like motion blur.

I actually already detect slowdowns in framerates or high CPU utilization (using your high-precision "performance.now" that you helped standardize), so TestUFO's logging knows 99% of the time if the framerate is low because of poor performance.
Posted by blurbusters on 7/23/2013 at 7:10 PM
Addendum: Another good 60fps versus 120fps demonstration is http://www.testufo.com/#test=framerates-text
(Run this in a 120fps-capable web browser on a 120Hz monitor)
Posted by blurbusters on 7/23/2013 at 7:07 PM
I observe that this issue has been closed as By Design.
I want to point out that this is still a deviation from W3C standard that all the other browsers are gravitating towards:

"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."
http://www.w3.org/TR/animation-timing/

When running a browser on Chrome (with chrome://gpu enabled, single monitor system, ATI or nVidia), it runs at 120 frames per second, as does Opera 15+ and FireFox 24+. Power users, such as users on HardForum, are purchasing increasing number of 120Hz monitrs -- especially the ASUS VG248QE (now only a couple hundred dollars) and this will become increasingly important in the coming years for Microsoft.

For an excellent demonstration that it's very easy to tell apart fluidity in 60fps versus 120fps, run TestUFO framerate comparisions: http://www.testufo.com/#test=framerates if you have a 120Hz monitor in-house -- it is quite obvious that following W3C recommendation is the Right Thing to do.

P.S. Chrome has a bug with fluid animations on multimonitor setups, so make sure to temporarily disable the secondary when testing Chrome on a 120hz monitor.
Posted by blurbusters on 7/19/2013 at 5:09 PM
I've added a hidden test, that measures requestAnimationFrame() timing fluctuations as a graph:
http://www.testufo.com/#test=animation-time-graph
It doesn't reveal why IE is abruptly slowing animation down on 120Hz monitors, but this is a useful visual graph tool.

I must compliment the Microsoft Internet Explorer team for having more accurate animation timers than both FireFox and Chrome; once you fix IE for 120Hz monitors, IE would be the best-performing browser in the Motion Test.
Posted by blurbusters on 7/16/2013 at 9:14 PM
UPDATE: Opera 15+ successfully does VSYNC 120Hz.

Now Internet Explorer is the only web browser of the major 5 that cannot do 120fps animations:
http://www.testufo.com/browser.html
Posted by blurbusters on 7/16/2013 at 10:04 AM
NOTE: Users have reported this problem. Three dozen 120Hz users said www.testufo.com only runs at 60fps in IE10.
However, I'm the first person to discover that the IE10 bug starts at exactly 105Hz.
Posted by blurbusters on 7/16/2013 at 10:03 AM
-- Animations suddenly halve refresh rate once you go from 105Hz -> 106Hz
-- I've been using NVidia Control Panel -> Custom Resolution to create custom refresh rate in 1 Hertz increments.
-- I've been able to reliably reproduce this on two computers

Possible sources of this bug in Internet Explorer:
-- You might be limiting based on "105Hz"
BUGFIX: Remove this framerate limiter. Search source code for number "105".
-- Or; you might be using a hard-coded maximum milliseconds value for a requestAnimationFrame interval, execution time-limit, etc. Change this hard-coded milliseconds value to dynamically change based on the refresh rate. e.g. If you're giving requestAnimationFrame a 9.5 millisecond time limit
POSSIBLE MAGIC NUMBERS that may be affecting this:
-- Search IE10 source code for "105" if you're using a framerate limiter
-- Search IE10 source code for "9.5" if you're using a milliseconds limiter (9.5ms is 1/105sec)
-- Or maybe IE10 may be using a different technique of limiting framerate, but hopefully this speeds up a 1-line bugfix in IE10. :-)
Posted by blurbusters on 7/16/2013 at 9:54 AM
Also -- requestAnimationFrame() is also designed to save power by throttling back when not used, but obviously, when you're running in foreground mode on a 120Hz monitor -- then you definitely want fluid animations.

However, it seems like Internet Explorer is unable to meet W3C standard when running on 120Hz monitors.
"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."
http://www.w3.org/TR/animation-timing/

Consequently, it is my interpretation of W3C standards for requestAnimationFrame() that Internet Explorer 10 has a bug with this API when running on 120Hz computer monitors.
Posted by blurbusters on 7/16/2013 at 9:47 AM
Ooops, I mean requestAnimationFrame(), found at:
http://ie.microsoft.com/testdrive/Graphics/RequestAnimationFrame/
Posted by blurbusters on 7/16/2013 at 9:46 AM
Hello Microsoft,

I have traced the problem to the JavaScript requestAnimationFrame() API call.
Here are the counts per second:

At 60Hz refresh -- refreshAnimationFrame() runs 60 times a second
At 75Hz refresh -- refreshAnimationFrame() runs 75 times a second
At 85Hz refresh -- refreshAnimationFrame() runs 85 times a second
At 100Hz refresh -- refreshAnimationFrame() runs 100 times a second
At 105Hz refresh -- refreshAnimationFrame() runs 105 times a second
At 106Hz refresh -- refreshAnimationFrame() runs 53 times a second (half refresh)
At 110Hz refresh -- refreshAnimationFrame() runs 55 times a second (half refresh)
At 120Hz refresh -- refreshAnimationFrame() runs 60 times a second (half refresh)
At 144Hz refresh -- refreshAnimationFrame() runs 72 times a second (half refresh)

Both Chrome (Since version 18) and FireFox 24+ (pre-beta), keeps running requestAnimationFrame() even at 120Hz, 144Hz, and even beyond (e.g. scientific 240Hz CRT's -- typically 2048x1536@85Hz CRT's that sync to 640x480@240Hz). Viewpixx (www.vpixx.com) also sells a projector that is capable of 500Hz native refresh rate.

Also, for www.testufo.com, I attempted to do a workaround by using a JavaScript timer that ran every 8 milliseconds (1/120sec), but animations were still very choppy; as if repaints were only being done at 60 times per second (frame rate limiter) on 120Hz computer monitors.
Posted by Microsoft on 7/16/2013 at 7:11 AM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team