JAKE: We should
talk about the web. SURMA: We should
talk about the web. And I have plans for the web. JAKE: Ooh! SURMA: Ooh! [THEME MUSIC] So I wrote a blog post. JAKE: Good. Good start. SURMA: I did not
squeeze it into a tweet even though we have twice
as many characters now. JAKE: Oh, yes. SURMA: I needed a little
bit more explanation. And I was-- the
entire event that sparked this interest is
a colleague telling me that there's iPad Pros and
that these iPad Pros run at 120 hertz. JAKE: 100-- that's
double the normal number. SURMA: It's 50 times 2. So, yeah, most devices that
we have worked with so far run at 60 frames a
second or at 60 hertz. JAKE: Right because it-- I remember in the
days of CRT monitors, you'd see quite a variance of-- SURMA: 24 hertz, 30, 50, 60. JAKE: Yeah, for a
computer monitor, you would tend to
run at 60, 75, 100-- SURMA: Oh, yeah, right. JAKE: Because the higher the
refresh rate, the less flicker. Yeah, the less eye bad it was. SURMA: On the scale
of 0 to eye bad. JAKE: It's like how
long can you watch it before your tears of
blood, that sort of thing. But then once the CRTs went
away, everything just 60-- 60 across the board. Laptops-- TVs can do it
differently because they want to synchronize the
frame rates but-- SURMA: We got also
24 so they're-- 6 is a multiple of 24,
which is sometimes an issue. JAKE: Right. SURMA: And Americans
TV run at 50. JAKE: American TV runs at 60. SURMA: European runs at 50? JAKE: European runs at 50. SURMA: Why? JAKE: Just-- sorry just allow
me to remove my smug grin. SURMA: I think I just
tapped into your specialty. JAKE: I've done a bit about
this in a talk a few years ago, and so I did a lot
of research into it. Yeah, it was all based
around the power frequency. SURMA: Yeah, exactly. You could just sync using the
wave form of the power supply. JAKE: So a 50 hertz here,
50 hertz in a lot of Europe, 60 hertz in America, and lot
of other places I think so. But, yes, we all decided, as
often happens, we'll just go, oh, we'll go with the
American thing whatever. 60 sounds better than 50. Whatever. We'll do that, which-- SURMA: Why won't
we take something it is a nice part of 100? Let's go with 60. JAKE: Here's the thing. If we went with 50,
we would all have more time on our frame budgets. Right? SURMA: Yes. JAKE: A significant
amount of time longer to get a frame together but no-- SURMA: 4 milliseconds more. JAKE: Exactly. But-- SURMA: But that's not the case. JAKE: That's not the case. SURMA: So and that's
basically the thing. Everything has been 60-- JAKE: But now we're going
to have even less time. SURMA: Well, kind of, yes. If you want to make
use of the 120 hertz, yes, but the problem is that
because every device has been running at
60, 60 has somewhat become an implicit assumption. JAKE: Right. SURMA: There is a good
amount of code out there that doesn't actually
consider how much time has elapsed since the last frame. JAKE: Who would write such code? SURMA: I don't know, Jake. Who would write such code? JAKE: So, yes. So on Twitter we were
talking about this because this was from
an Apple engineer. SURMA: So the thing is I
looked at the iPad Pros and looked at 120 hertz, and
I was like this is amazing. This looks so good. It actually makes a difference,
which I was honestly a bit surprised by. JAKE: I was dubious whether
you could notice a difference, but, yeah, you can. SURMA: If you think about it,
it makes sense because you-- if you think about you have
60 frames a second, especially with fast motion, so you
have more in-between images, which will make motion
blur seem much more real. JAKE: Yes. SURMA: Instead of having like
three individual pictures from A to B, you
will have now six. JAKE: Yes. Yeah, double that. SURMA: And it sort
of makes more-- your brain will think even
more it's an actual motion. And so I was asking what's the
plan, your wrath on the iPad. Still runs at 60. JAKE: requestAnimationFrame,
my assumption would be you would get a
requestAnimationFrame 120 times a second. SURMA: And you do not. JAKE: And you do not. SURMA: You get 60. JAKE: You get 60. SURMA: And that made me
sad because that basically meant whenever you were using
a animation framework that does the JavaScript animation
with JavaScript, which I think at least parts of
GreenSock, for example, do, you wouldn't get the 120 FPS. JAKE: Yes and I tweeted it when
a Safari engineer is saying why is this, and I
think they were saying, oh, well, we're worried
about legacy code that assumes 60 frames a second. And I was like, come on. Probably not a big deal. Probably not a big deal. Who does that? And they sent me back
one of my canvas examples from four years ago,
admittedly, but still-- SURMA: Shame on you. JAKE: Shame on me. SURMA: So that's something-- JAKE: So CSS animations
don't have this issue? SURMA: No they don't
because you are-- CSS by the very nature
of CSS is declarative, so either you use CSS
transitions where you say go from A to B in one second-- it doesn't care
about frame rate-- JAKE: You don't get visibility
into every frame so-- SURMA: Same with CSS animations. Same with web animations API,
which Safari is working on. It's not behind a flag so
you can start using it, which is really cool. JAKE: Oh! Oh, I did not know that. SURMA: Yeah, if you
use these technologies, the animations will run at
a 120 frames per second, and that's really cool. JAKE: So what's the answer
here for requestAnimationFrame? What can we do? How can we get that to-- it's going to have to be opt in. It my fault. It's
going to be opt in. But then even that demo
I did, it was some snow. Snow fell. And so on 120 hertz,
snow falls twice as fast. It's just a blizzard. It's fine. We can gloss over that. SURMA: Exactly. And then even if we solve
that, assuming we have a wrath and it's 120 hertz now,
we still have a problem because as you said we
have twice the frame rate. And that means half the budget-- JAKE: Less time to do it in. SURMA: And so with some
quick math in my head, I will tell you that
you are running, you would have an
8-millisecond budget per frame. JAKE: That is half of 16,
which we currently have. Yes. SURMA: Exactly. JAKE: Right. SURMA: But the problem is
that the work the browser has to do stays fixed, and
I think right about now it's safe to say it's between
4 and 6 milliseconds-- JAKE: Right. SURMA: On a desktop machine. It might change. Your mileage may vary. But that means on 60 FPS, you
still have way more than half left because let's
say that you have-- the browser needs
6 milliseconds. You have 10 left. 120 FPS, you have 2 left. JAKE: Oh. That's not a lot of time. SURMA: That is
not a lot of time. JAKE: Yeah. SURMA: And so there's-- of course, there's work
for the browser to do, optimizations to
only do work when it's really necessary
to make the things that have to happen
really fast, things that the browser can
optimize, but also I think the ecosystem
needs to change. It needs to look into
writing things in a way that they yield
often to the browser, that you can now-- they
can basically do here is my little chunks of
work and whenever you need to ship a frame
in between, here's the points where
you can do that. JAKE: So requestIdleCallback
becomes even more important. SURMA: Even more important. And the second
tool that you have and that not very
many people use is web workers,
where you can set up an actual separate thread
and do work in there. And you can block in there
you can do all kinds of work. The main thread won't care
and will stay responsive. JAKE: So something to
prepare for in 2018. SURMA: Definitely. JAKE: I think there's
an opportunity, if we did have go for
another function name, I think there's an opportunity
to rename requestAnimationFrame to something a little
bit more meaningful. SURMA: Yeah, it's not
the best name is it? JAKE: Yeah, so if it
was like before render. SURMA: Our request
on animation frame. JAKE: Right.
