The cause of

Today, a student in the group asked this question: What is the implementation mechanism of requestAnimationFrame

The problem is certainly familiar.requestAnimationFrameExecutes before the browser starts drawing each frame. With the help ofrequestAnimationFrameEfficient execution efficiency, we can userequestAnimationFrameDo animations, FPS calculations, and even increase the number of frames by counting the actual time each frame takes.

In MDN, there is another sentence: in most browsers that follow W3C recommendations, the number of times the callback function is executed usually matches the number of times the browser screen is refreshed. So YCK asked: What should I do if my screen refresh rate is very fast?

This sentence makes one ponder. In today’s era of high-brush monitors, I still use a 60Hz MacBook. Even though MDN says match, that’s not necessarily true. With this question in mind, I set out on a journey of discovery.

As a half digital party, for now digital products display refresh rate type or understand a bit. There’s 120hz, 144hz and so on. I searched for requestAnimationFrame status at 144Hz with the mentality of trying

The status quo

As expected. I did some searching and found a q&A post where the user said it used a 165Hz display, but the FPS calculated by requestAnimationFrame was still only 30-60fps.

That proves that the refresh rate is out of sync with the requestAnimationFrame for some users. However, in the answer area, some users also reported that their screen refresh rate was synchronized with requestAnimationFrame. This also proves that high probability is a Bug.

Is it really a Bug

So I went to the Chromium Bugs website and found such an Issue. Content was being written, using a 144Hz refresh rate monitor, but the FPS limit was still only 60.

So I dropped some of the arguments and went straight to the fix code and notes. Scroll down to find the chromium official’s explanation of only 60fps:

On Linux Nvidia we use GLX_SGI_video_sync to time vsyncs. Unfortunatelyit’s difficult to calculate an accurate refresh rate with it because itsvideo sync counter is wrong. Before, we hardcoded 60 FPS. Now insteadwe use xrandr to get the refresh rate of the primary monitor.

In Linux, the Nvdia driver used GLX_SGI_video_sync to calculate the time of vSYNcs (vertical synchronization) because of a counter error, so 60FPS was hardcoded directly. They now use XRANDr to get refresh rate calculations instead.

Xrandr is an official Linux RandR (Resize and Rotate). It can set the screen display size, orientation, mirroring, etc. Wiki.archlinux.org/index.php/X…

Since it is a Bug, let’s look at Chromium how to fix it

Repair the logical

Find the specific COMMIT record in the answer and link to the Chromium Gerrit platform. Come to this CR details

Go to the gl_surface_glx.cc file. GLX is hardware acceleration code in Chromium

As you can see, one of the float variables is called refresh_rate, which is the last value to calculate the refresh rate. Then, using (1 / refresh_rate), calculate the number of seconds controlled by a refresh. If it is 60 Hz, 1000ms / 60 times = 16.66ms once.

Here we continue with the calculation method of refresh_rate = > GetRefreshRateFromXRRModeInfo. Go to the x11_display_util.cc file to see the logic

As you can see here, the calculation logic is Pixel Clock/(Horizontal Total * Vertical Total). So what do these three numbers mean?

  • Pixel ClockClock frequency is the number of pixels drawn per second by the display.
  • Horizontal TotalThe number of horizontal pixels drawn per frame
  • Vertical TotalThe number of vertical pixels drawn per frame

That is, the number of pixels processed per second by the clock/(horizontal pixels) * (row pixels).

About Multiple Displays

As you can see from the code comments submitted to the Chromium Gerrit platform, multi-monitor support is problematic. Here’s another Bug to look at. This student uses a 144Hz + 60Hz monitor, but the output is still 60fps

So far, officials have only proposed solutions, but have not seen any commit results. So it’s still a Bug

Other reference

  • www.cnblogs.com/biglucky/p/…
  • Superuser.com/questions/6…
  • www.html5gamedevs.com/topic/17550…
  • Chromium-review.googlesource.com/c/chromium/…
  • Bugs.chromium.org/p/chromium/…
  • News.ycombinator.com/item?id=215…