Closed mdrejhon closed 3 years ago
domenic
commented
4 years ago This issue seems heavy on background information but unclear on exactly what the problem is or what is being proposed. https://whatwg.org/faq#adding-new-features might be a good read.
mdrejhon
commented
4 years ago (Was in midst of constructing a sequence of posts, that explains that rationale)
The current impetus for creating this issue is that we currently have a situation of inconsistency, but also a situation of defacto standardization.
For example, compliance of W3C HTML 5.2 Section 7.1.4.2, which is very widely implemented:
FAIL:
PASS:
Good debugging tools include vsynctester.com and testufo.com/animation-time-graph -- on some of my computers running an RTX 20X0 cards, the jitter is only 0.1ms, good quality enough for 480Hz and 1000Hz experimental displays. TestUFO was used at ASUS & NVIDIA suites to demo the new 360Hz gaming monitor using this animation, and it sync'd fine.
All known 120Hz mobile devices, with the exception of Apple 120Hz (iPads), currently correctly support 90fps and 120fps requestAnimationFrame() animations. Samsung, Xiaomi, Razer, OnePlus, etc -- all the non-Apple high-Hz mobile devices are becoming consistent (defacto standard) in their high-Hz behaviours.
We do realize some APIs (like requestAnimationFrame) are very poor for communicating animation intent. However, broad-spectrum consistency is required. Much like the discussion was forked on how to handle retina resolution a few years ago -- this is a new discussion that needs to be started in more consistent treatment -- pre-retina APIs were also square pegs in round holes too. ALL the APIs are on the table in maintaining Hz compatibility. Everything that moves/animates now need to consider Hz.
Otherwise, the world has a massive boom of new users complaining, such as this one.
Documents are 0 Hz, videos are 60 Hz, and browser-based demos (such as TestUFO) are one of the few Hz-adaptive methods of conveying animations. It helps market and sells phones / displays / etc in this new refresh rate trace. It transcends frame rate limitations of other media.
I think Apple would love to sell 120 Hz more. People google "Test my refresh rate" and "Test my screen" and "test my display speed" -- or any random phrase that tests display performance -- we are often tops in Google for that kind of stuff.
Logically it make sense there should be a solution. However, Apple's product is intentionally-incompatible (2017 design decision to run at only 60fps even on 120Hz iPads).
There is no adequate fillin APIs that are an adequate stand-in for requestAnimationFrame. TestUFO is simultaneously Hz-exact, Pixel-exact, and CSS animations cannot reliably reproduce tests such as this one and many others.
TestUFO is full of mainstream tests (i.e. Main Test, Game Test) and scientific tests (i.e. Ghosting Test).
While animation intent of requestAnimationFrame is poor -- it has a rather huge huge benefit of letting JS code generically able to self-monitor (e.g. execution time & execution cadence -- as seen in Animation Time Graph, as well as VSYNC Tester) which is something that other APIs do not have. That's why TestUFO is now scientifically trusted reliable, as it reliably self-detects majority of framedrops in nearly all GPU-accelerated Chromium implementations (TestUFO has over 30 different selectable tests at upper-right corner) and is now part of multiple scientific display-measurement test suites and in some peer reviewed papers. Sure, there are politics of pros/cons of each animateable APIs, but there is already a defacto W3C industry standard that needs to be fixed on the WHATWG side.
Many tests scientifically automatically self-invalidates (the LCD Ghosting test, the Frameskip Test) when a framedrop is detected, which is not possible with other animation mechanisms such as CSS animations. Some big pros outweighing cons for some purposes.
We understand Apple had some legitimate reasons. However:
Retina resolution was once a battery hog, but is no longer. We expect retina-Hz to follow a similar path.
We hear that 120 Hz iPhones are coming out, and this will be the starting pistol of commoditization of 120 Hz.
It is logical to resolve this problematic inconsistency BEFORE mega-popular 120 Hz phones arrive. iPhones are much more popular than iPads, and it would be a defacto big movement in mainstreaming 120 Hz. Thus, the recent escalation of priority.
mdrejhon
commented
4 years ago For people interested in how reliable high-Hz animations in TestUFO are -- for people who are concerned about machines not fast enough to perfectly framepace requestAnimationFrame (despite being a poor animation intent) --
To silence doubters on accuracy, and framepacing self-monitoring, here's a photograph of my Razer Blade 15 240 Hz laptop running www.testufo.com/animation-time-graph with less than ~0.2ms error margin!
Every single test at the upper-right corner of www.testufo.com runs perfectly at 240 frames per second on this battery powered machine (configured to appropriate power plan that maintains high Hz, of course). In the near future -- as mobile GPUs get more powerful -- it is likely all mobile GPUs will be able to do this without a problem or meaningful energy overhead.
Safari also sucessfully have sub-1ms margins on desktop Macs at 60 Hz. And some fast iPads manage sub-1ms too.
Animations do not stutter on Chrome unless there's an error of more than half a refresh cycle (Example: 240Hz = 1/240sec ~= 4.167ms ~= 2.083ms halftime), so it is easy to self-monitor for stutters in Chromium implementations. While this is not perfect, it's been a relatively reliable formula in the majority of browsers except Apple. A 0.2ms error margin is an order of magnitude safety margin, so the JS is relatively self-confident it's not stuttering.
This formula (half-Hz timing deviation) has been surprisingly reliable in self-detection of single stutters in GPU-accelerated browsers running modern hz-synced OS GUI compositors (practically >95% of users nowadays). Raising browser motion tests to scientific quality reliability.
We acknolwedge requestAnimationFrame was never originally designed to communicate a good animation intent. However, generic JavaScript has its great scientific virtues, including the ability to self-monitor framepacing accurately in a way that is relatively reliable on most GPU-accelerated browser engines.
I agree CSS animations are superior for other purposes though. However, it cannot serve TestUFO purpose or other high quality animations that helps advertise the virtue of high-Hz in a shareable medium. Also, requestAnimationFrame has the benefit of the simultaneous ability to be simultaneously pixel-exact AND frame-exact -- in a sufficiently deterministic manner using the above framedrop-detect algorithm.
However, there are very advantageous reasons that requestAnimationFrame is often superior for demonstrating high-Hz benefits -- including the generic ability to self-monitor fluidity of animations (time interval between requestAnimationFrame). This is a big advantage of generic JS to inform the user that the performance of their browser is not good enough to run TestUFO at full frame rates (mainstream motion tests) -- or to invalidate a test (scientific motion tests).
Works -- All current versions of all desktop browsers Works -- Razer 120 Hz phones Works -- Pixel 90 Hz phones Works -- OnePlus 90 Hz phones Works -- Xiaomi 144 Hz phones Works -- Samsung 120 Hz Galaxy (Google Analytics shows Samsung useragents green at 120Hz!) DOES NOT WORK -- Apple 120 Hz iDevices
And now the burgeoning 120 Hz phone boom coming this 2020s. Thus, the reason I introduce myself to WHATWG at this juncture.
mdrejhon
commented
4 years ago Even iPads are accurate enough to framepace 120 Hz perfectly.... If the arbitrary 60fps-cap could be removed. Here's a few screenshots of my iPad Mini running the TestUFO accuracy self-monitoring code. The self-benchmarking data can be found at www.testufo.com/animation-time-graph
Here's a screenshot of my very own iPad Mini 5 framepacing at sub-millisecond accuracy.
Here's a screenshot of my very own iPad Mini redrawing a custom graph 60 times a second, one pixel at a time in generic JavaScript, in a mere 4 milliseconds each redraw. The graph code is actually inefficient -- it is currently redrawing the whole graph from scratch 60 times a second (background clear, lines, text, single pixels, etc)
(You're even witnessing the granularity of Meltdown/Spectre 1ms-timer-fuzzing built into Safari -- so it's more granular looking than when running this under Edge or FireFox. Fortunately, refresh cycles are much more coarse than 1ms, so it's still relatively easy to self-monitor for single-framedrops).
Things are even better on the new 120Hz iPads, which have faster performing GPUs than the lowly iPad Mini. In some cases, the redraw of the graph in generic requestAnimationFrame javascript, takes only a millisecond on Apple's own product! Yet Apple still limits the requestAnimationFrame frame rate to only 60Hz, hurting the self-advertising of the 120Hz feature. While there's still power consumpton concerns, it's became much less now than 2017. And faster screens means 60Hz vs 120Hz has become much more visible.
Documents are 0 Hz, Videos are 60 Hz, and browser animations are one of the few easily-shareable methods of advertising 120Hz. If Apple wants the world's social media to help share the benefits of 120 Hz, they need to solve this.
It is apparent that prior legitimate rationales against are becoming less valid. As of 2020, it is time to standardize the WHATWG side to make requestAnimationFrame() properly consider high-Hz devices in this emerging new refresh rate race.
mdrejhon
commented
4 years ago If Apple is reluctant (i.e. power overheads not low enough yet) -- then perhaps a compromise could be reached, like a vendor-prefix API and/or permission-9based JavaScript request.
Other APIs (SVG, CSS animations, etc) are currently unable to meet needs (in current implementations), and broad-spectrum retina Hz compatibility is needed, much like all APIs had to be updated to accomodate retina screens. Naturally, a compromise standards path becomes needed, if Apple prefers not to follow the defacto standard path; Previous reasons (power, efficiency, visible differences, etc) in 2017 are increasingly less valid in 2020 as explained in above posts.
Much like asking for microphone permission or asking for full screen permission. In order to request permimssion for 120fps. Even if it's a temporary Safari-specific solution until full standardization.
I am willing to modify TestUFO to meet a vendor-prefix or a permission-request call. A solution needs to happen is before the boom of mainstream 120 Hz.
My ulterior motive? TestUFO are 100% free tests for the public good, in a rising-tides-lifts-all-boats to grow the 120 Hz industry. Everybody wins. Even Apple, if there is a solution or a compromise. And TestUFO is not the only motion tests on the web, but it's the most popular. Remember in shareable media, documents are 0 Hz, video sites are 60 Hz, web animations unlock this limitations in sharing the benefits of 120 Hz. This is a logical way in communicating/educating during the new refresh rate race. Everyone wins.
As a reminder for fps=Hz requestAnimationFrame()
Works -- All current versions of all desktop browsers Works -- Razer 120 Hz phones Works -- Pixel 90 Hz phones Works -- OnePlus 90 Hz phones Works -- Xiaomi 144 Hz phones Works -- Samsung 120 Hz Galaxy (Google Analytics shows Samsung useragents green at 120Hz!) DOES NOT WORK -- Apple 120 Hz iDevices
iPhones are far more popular than iPads. Thus, a compromise that allows consistency on 120 Hz phones without user complaints like these that are found in numerous places -- this could be bad publicity for Apple when more than orders of magnitude users begin tryng to show off / benchmark 120Hz with the emerging mainstream 120 Hz boom. No other shareable mediums (documents or videos) are as refresh rate adaptive.
Thus, may hurt other 120Hz initiatives (like future 120Hz Apple laptops or desktops). It is in the world's interest to make sure there's an easy mechanism to demo in a shareable medium that is not framerate limited (like PDF documents or video files) -- as it helps sell the complete entire 120 Hz world. Rising tides lifts all boats and technology progress.
Other standardizations towards high-Hz world can be gradually covered in due time (scrolling engine, JS engine, WebGL engine, CSS animation, etc -- it's why I posted in meta).
But requestAnimationFrame() is currently a major lone-vendor-standout consistency weak link at this time that needs some unique decision-making expediency.
Discussion on near-term solutions welcome!
mdrejhon
commented
4 years ago Workaround Attempts
Detect model of iPad supports 120 Hz (useragent detection) and attempt: (A) to use a timer event running 120 tmes a second (bypass requestAnimationFrame) (B) to run two redraws per requestAnimationFrame(), with one event timer-triggered between callbacks
These workarounds did not work because the screen still updated at only 60 times per second. Apparently the browser's internal compositor is only occuring 60 times a second when I tested this. Even when I try to force redraw 120 times a second, it still only presents 60 visible frames per second.
This is presumed an efficiency consideration.
One possible solution (if Apple is OK) is a flag or call to signal desire for full refresh rate on a demand basis. Only when JavaScript developers who want to trigger higher refresh rates (and allowed only when device is not running in battery saver mode). This can be thus be invoked only for specific pages -- such as TestUFO -- solving the lone-standout problem.
unphased
commented
4 years ago Do you think it’s maybe because Apple doesn’t want to reveal through this whether the new iPhones will be 120Hz? I cannot imagine this not being addressed since it’s a fully preventable way to avoid negative PR from a pretty vocal group of people. I got here looking to make my three.js scenes render faster than 60 on my iPad Pro, but was surprised to learn rAF and the entire compositor are apparently locked at 60. Thanks for the info!
mdrejhon
commented
4 years ago @unphased -- The newer iPads are already 120Hz, so that wouldn't be the reason.
Have you tried the latest iOS betas and see if the problem still persists?
unphased
commented
4 years ago The newer iPads are already 120Hz, so that wouldn't be the reason.
Yeah I can't think of sensible logic for it given iPad pros have been 120 for a while, meaning they acknowledge its benefits. But such logic may still exist, something we haven't considered...
cgrobb
commented
3 years ago @mdrejhon and others. It strikes me that the folks working on color, especially HDR, have provided a roadmap for how to co-ordinate something like HFR across web, display, and content creation technologies.
https://w3c.github.io/ColorWeb-CG/
Perhaps many of the same folks who participated in the color/HDR-related standardization would be interested in doing the same for HFR.
svgeesus
commented
3 years ago My suggestion would be to create a High Frame Rate CG. I can help with that if needed. I can also post an announcement to the Color on the Web CG once it is created, because indeed there may well be overlap of interests. Lastly, the model of a CG report which tracks issues and centers discussion does seem to be a good one.
mdrejhon
commented
3 years ago I'd be very interested in working a High Frame Rate CG. I would like to collaborate with someone who has experience running CG's, so if you already have experience, please get in touch with me!
This is a boom this decade since we've retina'd out spatially, but we are far from retina'd out temporally. Thanks to the 360 Hz gaming monitors, there's been a continued refresh rate, and ASUS is road-mapping a 1000 Hz gaming monitor (genuine refresh rate, non-interpolated). Due to the science of how motion works, there's a measurable humankind benefit to increasing refresh rates even for non-gamers (doubling refresh rates halves motion blur on sample-and-hold displays, which benefits clearer browser scrolling -- like 120Hz smartphones). The diminishing returns dictates a need to continue doubling refresh rate (60-120-240-480-etc) to get any measurable humankind benefit that allows LCD/OLEDs to better emulate CRT motion clarity, but technologies to retina-out temporally are arriving in the coming decade. We cover this in the Area 51 Display Research Section ( blurbusters.com/category/area51-display-research http://www.blurbusters.com/category/area51-display-research ).
Within this group we should discuss variable refresh rate implementation issues. We have a number of other chicken-and-egg problems, such as the NVIDIA drivers blacklisting browser executables for variable refresh rate (because of lack of variable refresh rate support) but this gets bypassed when renaming browser executables. Once VRR support gets added to a browser, I have contacts within NVIDIA that can work to remove the browser blacklist.
Thanks, Mark Rejhon Blur Busters / TestUFO
On Thu, Aug 13, 2020 at 12:47 PM Chris Lilley notifications@github.com wrote:
My suggestion would be to create a High Frame Rate CG. I can help with that if needed. I can also post an announcement to the Color on the Web CG once it is created, because indeed there may well be overlap of interests. Lastly, the model of a CG report which tracks issues and centers discussion does seem to be a good one.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whatwg/meta/issues/158#issuecomment-673586753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOJUBFZCNKJL322AHGSW74DSAQKHVANCNFSM4KH4SGYA .
voormann
commented
3 years ago This is most likely a power saving feature as most people don't use the web browser in iOS for playing games or other things that benefit from high refresh rates. Do you still only get 60 FPS when it's plugged into a charger? If so, Apple should fix that.
On a side note, there should also be a way to detect the refresh rate of a monitor without relying on requestAnimationFrame. That way we know the full potential of the display and it will greatly benefit games that rely on delta times for consistent animation speeds across different refresh rates.
mdrejhon
commented
3 years ago No, Apple still says 60.
Yes, discovery is recommended and I also write about this here: https://blurbusters.com/adding-variable-refresh-rate-support-to-html-5-2/
Could we produce a new Working Group that involves this? I'd like to participate in one.
I agree a more direct discovery method of refresh rate is needed, similar to detecting screen resolution, etc. Although requestAnimationFrame() is somewhat of a crude method of refresh rate discovery, it is mostly reliable on non-Apple platforms. requestAnimationFrame has no problem with 120Hz, 240Hz and even 480Hz (see www.blurbusters.com/480hz for actual requestAnimationFrame() tests ...) for various scientific tests that are in-browser, as I am the peer-reviewed co-author of a display motion blur testing method. Doubling framerate and Hz halves motion blur on LCD and OLED screens, including text scrolling and map panning, so 120Hz is useful for non-game purposes -- if you view www.testufo.com/framerates-text on a 120Hz screen, text scrolling has half the motion blur everytime you double the refresh rate, 60Hz->120Hz->240Hz on a sample-and-hold technology such as LCD and OLED.
Thanks, Mark Rejhon Blur Busters / Rejhon Technologies Inc.
--- An Important Note From Our Legal Beagles ---- This message is intended solely for the named recipient, and may contain confidential information protected under applicable law. Any unauthorized dissemination, distribution, copying, or the use of information contained in this email is strictly prohibited. If you have received this communication in error, please notify the sender and delete this email immediately. --- Fin ---
On Thu, Sep 17, 2020 at 5:55 AM voormann notifications@github.com wrote:
This is most likely a power saving feature as most people don't use the web browser in iOS for playing games or other things that benefit from high refresh rates. Do you still only get 60 FPS when it's plugged into a charger? If so, Apple should fix that.
On a side note, there should also be a way to detect the refresh rate of a monitor without relying on requestAnimationFrame. That way we know the full potential of the display and it will greatly benefit games that rely on delta times for consistent animation speeds across different refresh rates.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whatwg/meta/issues/158#issuecomment-694126709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOJUBF6IISZYYYEP24TOTXLSGHMFJANCNFSM4KH4SGYA .
voormann
commented
3 years ago That sounds like a brilliant idea.
I propose these three discovery methods:
The second method would be very useful for web games. You know when you get the stutter warning on Blur Busters because of some heavy background task? You obviously lose FPS but it also creates a "jumpy" animation effect in games that rely on delta time (time between each frame) to keep animation speeds consistent across different refresh rates. Long story short, having the browser saying "hey, I'm going to run this page at x FPS" will fix this unwanted effect.
Furthermore, the two first values can be updated with an event listener (much like the window resize event). This is very useful if the user has a dual monitor setup and moves the browser window from a display with 144 Hz to a 60 Hz (or vice versa). The third method can simply return the current frame time (e.g. 16.6666667 for 60 FPS) much like the window.performance.now().
On a side note, I agree with the fact that higher refresh rates enhances even the most common tasks, but having better battery life when I'm out and about is definitely a higher priority.
mdrejhon
commented
3 years ago As for the discovery methods:
Many scientific tests needs to immediately invalidate a test (notify the researcher or camera) upon detecting a single frame drop stutter. I am able to do that reliably with Chromium-engined and Webkit-engined browsers using the requestAnimationFrame timestamping and performance.now() capabilities.
Web Animations API does not allow me to do this.
Also 120Hz capability in web browsers could be enabled/disabled in a Preferences setting. As time passes, the power cost difference of 60Hz and 120Hz is steadily dropping. At the minimum, when the device is plugged in, there should not be a downgrade in frame rate.
annevk
commented
3 years ago I recommend raising this with the https://wicg.io/ community. They might be able to turn this into a proper proposal.
lgarron
commented
2 years ago For what it's worth, I'm sad to see this closed without a clear path forward. :-(
I know one vocal person is not reason enough, but I think @mdrejhon has been a rather patient and thorough advocate. Given that 1) every browser other than Safari seems to supports this, and 2) WebKit is able to handle CSS animations at 120Hz (I believe), it sure seems like there is no major technical barrier to an API that supports high frame rates in all browsers.
I've added a comment on the relevant 120Hz rAF WebKit bug for now: https://bugs.webkit.org/show_bug.cgi?id=173434
I recommend raising this with the https://wicg.io/ community. They might be able to turn this into a proper proposal.
Is there an effort for this yet? While I'd love to think that 120Hz on iPhone (as rumored) might be enough reason for Apple to support 120Hz rAF, there are a few legitimate concerns that they wouldn't disclose unless there is movement towards a spec. (For example, they might have battery concerns that could be addressed by requiring the page to call an opt-in API for >60Hz.)
annevk
commented
2 years ago There is a clear path forward, no? That is, interested parties can write up a proposal and submit it to WICG for incubation.
lgarron
commented
2 years ago There is a clear path forward, no? That is, interested parties can write up a proposal and submit it to WICG for incubation.
Hmm, I have to admit that I never really figured out how the WICG works and https://www.w3.org/community/ is a little opaque. I assumed you had to be a browser or be experienced in writing web standards to properly participate. Is there a good official "WICG for the mostly unaffiliated individual" guide?
annevk
commented
2 years ago I'm not really familiar with WICG myself, but looking around a bit just now I found https://github.com/WICG/proposals which seems to be the entry point for new things these days.
mdrejhon
commented
2 years ago Hmm, I have to admit that I never really figured out how the WICG works and https://www.w3.org/community/ is a little opaque. I assumed you had to be a browser or be experienced in writing web standards to properly participate. Is there a good official "WICG for the mostly unaffiliated individual" guide?
I would like a volunteer guide person / co auhor to help me trailblaze beginning this process of creating a proposal and starting this process.
If you rather not collaborate publicly here, please contact me at mark [at] blurbusters.com as we aren’t familiar with the WICG universe.
mdrejhon
commented
2 years ago Is there a good official "WICG for the mostly unaffiliated individual" guide?
Also, Blur Busters is no longer just a single individual, but now a startup company too -- though ten years ago it did start as a hobby, it has become a niche force over the years. (an example is services.blurbusters.com) -
My business -- Blur Busters / TestUFO -- is now in many peer reviewed papers and the output of our tools are used/witnessed/viewed by tens of millions in the gaming industry if you include the photo/video/graphs inserted into youtuber/web reviews of gaming monitors -- since most display reviewers worldwide who go so far as use benchmark tools on displays (LinusTechTips, PC Magazine, PC Gamer, TomsHardware, etc, etc) show off the results from one of the Blur Busters testing inventions. And we have worked directly with some manufacturers such as ViewSonic XG2431 (BusinessWire)
To those in the industry I'm the "refresh rate Einstein" of the industry, and huge numbers of professional players and salaried game developers world wide recognize the UFO logo (of my avatar). When me (Canadian) walks into a convention of display manufacturers in Asia, I seem to be a rock star (recognized by the manufacturers too) -- like this one. If you work in other industries such as SAP or databases or CRM, you probably haven't heard of me. So I'm surprisingly well known inside this niche, but not as well known outside.
It's starting to become apparent 120 Hz is slowly becoming somewhat mainstream towards the end of this decade. So standardization pressure is already increasing, even though Android web browsers have fallen in line, iPhone web browsers have not yet (not even the "Chrome" app, due to its requirement of using the Apple HTML engine)
Android & iPhone are slowly becoming 120 Hz included (soon you can't buy a new Samsung Galaxy without a 120Hz feature). All recent XBOX consoles (the last two generations) and and PlayStation 5 (the current one) now support 120 Hz. And even more than half of the cheap generic new TVs manufactured 2021 now include the 120Hz feature. Even generic TCL HDTVs manufactured this year and on sale for $499 (and less) now include 120Hz as a standard feature.
However, this matter is important outside of games too -- the Apple 120Hz ProMotion iPads show the slick smoothness of 120Hz in everyday use too. In the industry, even Dell/HP is talking about 120Hz being added to office monitors for ergonomic features (since it halves scrolling motion blur in everyday work, etc).
In other words -- by end of the decade, it will be increasingly hard to buy a display without 120Hz support. Much like 720p HDTVs are hard to buy; and 4K is cheaper than yesterday's 1080p.
There's a boom of people buying 240Hz monitors for non-gaming uses, ever since 240Hz arrived to high-quality above-1080p color IPS panels, even just for more beautiful scrolling (better scrolling than a 120Hz ProMotion iPad) with brand new 2560x1440 resolution 240Hz wide-gamut IPS panels now hitting the market.
As a founder, I'm being pulled in many directions operating the startup - so a co author to help me out in creating this proposal would be excellent, to balance things out and peer-review things more.
The only reason I have a monopoly on TestUFO and my logo seen by dozens of millions (thanks to its use by mainstream technology websites), is because of lack of web standards -- that's almost mic drop worthy here, isn't it?
Rheoretically asking this audience -- why should I have the near-monopoly on browser-based display benchmarks because of lack of web standards? However, it's not a monopoly I'd expected to keep for so long (Almost a decade), since some tests are dependant on browser-specific magic sauce techniques such as reliable stutter-detectors (e.g. detecting when a frame was missed), such as www.testufo.com/frameskipping ... I have too much useragent detection in TestUFO only because of sheer lack of web standards pertaining to high-Hz benchmarking purposes.
There are some surgical reachouts I've already tried (e.g. @smfr) but I think I need to broadcast a wider net to get a power-management-friendly WICG proposal started;
P.S. Another magical use of TestUFO recently appeared -- I now teach high-Hz masterclasses to display companies and industry vendors who don't understand high Hz. Have already been hired to fly over both Pacific and Atlantic. It heavily utilizes TestUFO animations as the equivalents of high-Hz show-and-tell demos with high-Hz equipment;
(Left monitor: testufo.com/photo for testing LCD GtG ghosting; and middle monitor: testufo.com/crosstalk for testing BFI strobing modes, OLED BFI, plasma TV, and other low-persistence motion blur reduction modes)
mdrejhon
commented
2 years ago Because as Founder of my business -- my workload is massively increasing in the massive high-Hz boom, I have no time to write standards proposals anymore without listing and crediting co-authors.
So again, I am requesting HELP please -- email mark [at] blurbusters.com -- appreciated! Your name will be in lights as a co-author in these specifications and proposal documents to various web-based working groups. Both on the media website & on the behind-the-scenes research. Hey -- with Blur Busters now sufficiently famous this tight (but expanding) niche -- maybe it'll help you get your next job in a booming industry; so consider credit as an incentive to help out on this proposal document?
Downrating the priority of this item just because some outside my niche just sees me (understandably) as an "individual" because I'm famous to millions in a rapidly expanding-and-mainstreaming niche.
Look over the cubicle wall: I know that you Visual Studio developers using 60Hz DELL in a cubicle, probably aren't yet too familiar with the benefits of high-Hz (even for non-gaming uses), and might view this item as a low-priority, but a rheoretical question:
Mega YouTubers viewed by millions use my TestUFO tests in-video and mention "Blur Busters" or "TestUFO" at least once -- such as LinusTechTips and dozens of others. And display manufacturers now cite TestUFO website in more than 20 peer reviewed research papers, after all... Manufacturers, benchmarkers, bloggers, youtubers, esports players, in an expanding market that now includes a mega boom of non-gamers (120Hz and 240Hz as ergonomic feature like 120Hz iPads instead of for gaming).
120Hz is mainstreaming under our noses, and we all need to team work to resolve this;
I'm open to privately or in another appropriate public venue -- I'm flexible, just need to spread standardization workload a little bit. Since my workload is very big nowadays and can't do a full spec 100% solo, to an industry full of cubicle workers and laptop WFHers using DELL 60 Hz laptops and many departments at Fortune 500 companies are unfamiliar with high-Hz.
Both my (better-than-60Hz display industry) and your (browser industry) industry are huge expanding pies that don't seem to overlap much.
Despite the gaming industry now bigger than the Hollywood industry -- the venn diagram of people in these industries (your industry and my industry) are very non-overlapping venn diagram in technical-expertise knowledge.
Game developers are not familiar with web standard development, and vice versa -- etc. Which is why I have difficulty (finding | hiring | volunteering | collaborating | etc) on this as of late. So I'm making a calling out.
So help me punch a signal through all the noise. I have formal spec writing experience -- one of my fancy works with my name as main author is https://www.xmpp.org/extensions/xep-0301.html -- just not enough time to write specs solo anymore. So I'll add heavy lifting, but I need an email WICG guideperson to help me navigate this (templates, contacts, background knowledge of power-management concerns at Apple/Google, etc, etc).
Depending on how surgical the help is -- this won't take much of your time. Even a mere hour or two (combined, totalled) of help over a period of 6 months (or sooner) is all I need to see this get kickstarted. Something more than a single HOWTO for this surgical proposal. An email WICG guideperson will help me save lots of research time. Just starter kindling that kickstarts a snowball collaboration. A template there, an advice there, ongoing work gets a new volunteer gets interested, a prefilled paragraph there that I expand 5x, etc, etc, Essentially collecting the campfire kindling, metaphorically speaking.
Email: mark [at] blurbusters.com to begin discussing how to collaborate with a very effective proposal pitch to WICG.
Thank you!
unphased
commented
2 years ago As a long-time 120Hz enthusiast (Been on sub-10ms since 2011!) it's always been obvious that I would pay a premium for a higher refresh rate display because it "just feels better". One thing I wanted to suggest for bringing more awareness to help garner more interest is to emphasize that higher refresh rates provide for reduced latency.
It seems to me that having more data rate isn't necessarily inherently as convincing as an argument for the fundamental ergonomic benefit of reduced latency. Perhaps many users tend to think of it as a sort of upper limit, rather than the pervasive and ever-present improvement that it presents in computing tasks of any kind. The point being that it is not the same as upgrading your internet connection speed, from which you would not gain a benefit except in a narrow band of situations.
Perhaps it is a more sound way to reason that the improvement in feel comes directly from the reduction of latency. The increased refresh rate is a direct result of reduced latency, rather than the other way around.
I can imagine a future where we would move away in all software stacks from fixed refresh sync points and establish asynchronous APIs so that e.g. only the portions of the screen that change need to be refreshed would be refreshed, and also done at the precise time specified by software. What we have now is already a good amount of the way to reaching such an ideal. You could imagine when this is possible we could in theory refresh a mouse cursor at, say, 4khz, on hardware that would otherwise only be capable of updating the entire buffer at 240hz.
Just as the evaluation of game performance has seen a move forward from FPS numbers to ms per frame numbers I think talking about latency with the second unit is closer to the core of it than talking about the inverse second unit, though I guess the marketing aspect of bigger number being better remains significant as ever.
numerized
commented
2 years ago Hello there, where are we on this thing?
mirh
commented
1 year ago Yearly bump. This would also address an old thread you had. https://discourse.wicg.io/t/proposal-allow-developers-to-indicate-their-ideal-frame-rate/4422
Surely there's somebody at google eyeing on this stuff?
Now that I (founder) and Blur Busters (organization) has formally joined the WHATWG standards process, I'd like to introduce myself -- I'm the creator of the popular www.testufo.com motion tests that you now see in the news relating to almost anything high-Hz.
The Need To Standardize Browser Behaviour For High-Hz Display Technologies
There is a browser consistency problem with standardization of animations at high refresh rates.
First, My Credentials
For those unfamiliar with my work in high-Hz, I'm the founder of BlurBusters.com and creator of TestUFO.com, and have a Display Engineering discussion forum. I've got references in a paper by NVIDIA (see Page 2) and paper by NIST.gov / NOKIA / Keltek (as coauthor), as well as other. Also, NVIDIA recently commissioned Blur Busters to create a custom TestUFO test for the recent 360 Hz gaming monitor. W3C accepted my commit for a modification to HTML 5.2 specification (Section 7.1.4.2) for fps=Hz requestAnimationFrame()
Refresh Rates Is a New Frontier Of Tech Advancement
Just as 4K was niche (IBM T221 in 2001), it is now commoditized ($299 Walmart Black Friday). This decade, 120 Hz is becoming commoditized in upcoming phones and displays.
The spatial cow has been milked (retina resolution), and only now the temporal resolution cow has begun to be aggressively milked by industry (retina refresh rates). Recent scientific tests have shown that even 120Hz-vs-1000Hz has more human visible differences than 4K-versus-8K. Even ASUS now has a long-term roadmap to 1000Hz gaming monitors (directly confirmed to me, to PC Magazine, and to other journalists).
Those unfamiliar with the benefits of refresh rate race (it even benefits browser scrolling, not just video games), can study blurbusters.com/1000hz-journey including its scientific references. Other useful articles include Frame Rate Amplification Technologies which NVIDIA has confirmed they are working on; as well as Stroboscopic Effect of Finite Frame Rate Displays.
Upcoming Commoditization Of 120 Hz This Decade
The next iPhone and Galaxy will support 120 Hz refresh rates, accordingly to widely-reported sources.
Just as 120 Hz is about to become commoditized, future higher Hz will later become commoditized when costs (financial, power, efficiency, etc) and speed (e.g. GtG tiny fraction of refresh cycle duration) -- the human visible benefits become amplified.
It is observed that 60Hz vs 120Hz on OLEDs is much more visible than 60Hz vs 120Hz on LCD. Additionally, is observed that 60Hz vs 120Hz is much more visible on retina displays (more pixels to have artifacts over the same inch). Tech progress has recently amplified the differences between refresh rates, and has created additiuonal pressures for higher refresh rates. Refresh rates that were formerly bleeding edge (like retina resolution or 4K), are slowly being commoditized.
Past Concerns Gradually Becming More Moot
Efficiency is much higher, battery consumption is less of a concern in 2020 than 2017, compatibility became defacto standardized (as webpages made modifications) -- It is now time to formally standardize a WHATWG standards process for browser treatment of high refresh rates, in various arenas:
A broad-spectrum inclusion is required, much like what happened for retina resolution support, as processes needed to include all APIs (legacy and newer).
Other References
Prior article about W3C standardization of other techs https://www.blurbusters.com/blur-busters-working-on-changes-to-html-5-2/
Past article about 120 Hz Web Browser Benchmarking https://www.blurbusters.com/blur-busters-120hz-web-browser-tests/
Recent article about 144 Hz Webkit support in non-Apple phones: https://www.blurbusters.com/xiaomi-uses-testufo-to-demo-144-hz-redmi-5g-smartphone-apple-does-not-support-120-hz-testufo/