120fps – HTTP203

120fps – HTTP203


14 comments

  • So 120fps is good for the web? 🤔😨

  • Great discussion

  • 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

  • When you said 120 HZ I could only think of the razer phone, completely forgot about the Ipads. XD

  • 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.

  • but the time in requestAnimationFrame wasnt supossed to be according 1/fps from the monitor?

  • "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?

  • Я ничего не могу понять поэтому дизлайк,слишком плохо, слишком…

  • I'm already struggling to hit 60fs with canvas and svg animations in D3. Can't really imagine having to deal with 120fps.

  • 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

  • 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.

  • 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.

  • It will be so cool if YouTube can support 120fps

Leave a Reply

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