120fps – HTTP203
Articles,  Blog

120fps – HTTP203


15 Comments

  • Omri Katz

    CS (Counter Strike) hard core gamers always buy a 90/120HZ monitors or even 144HZ, been like this for years. Hopefully the browser will catch up soon

  • headjobs

    Our team is focused on mobile. Running at 60FPS is hard enough! For f sake guys. Another wall between Google and devs. Running at 120 will be damn near impossible. Even with RAF. Opt OUT! 2ms budget LMFAO!!!!!!!!!! Clueless.

  • Erik Trom

    "requestIdleCallback becomes even more important"…. I agree but – from Safari Preview – Release 50 (Safari 11.2, WebKit 13606.1.5) — "requestIdleCallback" in window => false (its been missing for some time now, not sure how long, but worth noting, apple must have something else planned?

  • Eduardo RFS

    I really like 120hz, but the time problem is real, even small events(like keypress without js handler) the frame time variation is so high, in my desktop, take like from 2ms to 20ms. I think it can be windows scheduler, but if it happens on a desktop with a 3ghz+, what will happen on a ARM?

    And sorry, it's a really good talk, but, i can't wait more a +18 version. Come on surma and jake, do it for us

  • Eduard Urbach

    Using a 144 Hz monitor for the past 4 years while browsers/apps have been trying to reach even 60 FPS, I can definitely relate to this problem. Good talk.

  • foohyfooh

    To solve the problem make a new requestAnimationFrame method that takes a parameter which states the fps that you want to do. So make constants for 30, 60, 120, etc and pass that every time you call the method.

  • emilemil1 | Nightcore

    One thing I'd really like to see that I think would help greatly with improving FPS, is some kind of way to give code different priorities.

    For example if you click to open a dropdown you want the code that triggers any style changes and network requests to fire immediately, it's of high priority. You might also want to precompute some future content that may be needed if a button on that dropdown is clicked. That's not as time-critical since there will most likely be quite a few frames until that content is needed, so it's of lower priority. Lastly you might want to gather some analytics that the user clicked on that particular button, and that's of very low priority.

    This would basically translate to a priority hierarchy where higher priority work always runs before lower priority work. The browser's own jobs, such as calculating styles, would take precedence over pretty much any code that isn't assigned as being high priority. This would make it much easier to write code that doesn't block animations. Lastly it would be excellent if you could also mark code as interruptible, meaning that higher priority code can interrupt that code mid-execution and push the remainder back onto the event loop.

  • POVHFR Videos

    120fps and 240fps is great as well. The human eye can actually see up to around 4000fps, imagine a 4000hz monitor.

Leave a Reply

Your email address will not be published. Required fields are marked *