Motion Design with CSS Frames Per Second

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Rachel Nabors: Let's talk a little bit about Frames per Second, or FPS.
>> Rachel Nabors: So frame rate on the computer is definitely not the same as it is in the movie theater. For instance, in the movie theater the optimal frame rate to maintain this illusion of life is 24 frames per second.

[00:00:26] Whereas on our computer we keep hearing people throwing around things like 60 frames per second. How can those numbers be so disparate? How can movie theaters get away with 24 frames per second, and we have to go out there and refresh the screen 60 frames per second? It's ridiculous, right?

[00:00:42] Well that's because some photography has this lovely thing called motion blurs. You'll notice that each one of those 24 frames has this rather, when someone's moving really quickly, has this smear of action showing an area where something is moving. The human eye actually sees motion areas like this.

[00:01:02] It's hard for me to describe how the human eye works, because we tend to think of it as like a camera. And while it is taking in data like a camera is, it is not processed in a photo realistic way in our brains. It is used to create mental models that we experience.

[00:01:15] Our mental model of what we're experiencing cannot be distilled down to 60 or 200 frames per second. It becomes areas of motion or areas of change that look a lot more like this if I had to visually represent them to you. Doing my best here without having to bring up a whole like I'm going to take the place of [LAUGH].

[00:01:38] We're going to do like a Nova special where I'll be like, hi I'm Rachel Neighbors, and today we're going to go on a magical experience where we're going to learn how your human visual system processes information. We're not doing that today. So, I will just show you with words and pictures as best as I can and not do any mind blowing.

[00:01:59] So there is this lovely, this is done in Animation too, and this might be copyrighted material so the videos might have this blanked out. But if you go to animationsmears.tumblr.com, you can see some examples of how this is done in animation. For instance this is from Totally Spies and you can see that this is a single frame from Totally Spies and you can see how our hands are moving all around in this one frame.

[00:02:27] It makes it look like it's happening really fast when you're playing these at 24 frames per second. And the human eye is totally taken in by this, cuz that's a lot like how it's processing images.
>> Rachel Nabors: So,
>> Rachel Nabors: [COUGH] More than anything, consistency is the more important thing.

[00:02:48] It doesn't matter if you're hitting 60 frames per second for some of your animations if others of them fall down to 30 frames per second. The human eye will notice that inconsistency and it will pay attention to it. It's not like you're cool so long as you most of the times hit this goal.

[00:03:04] If you're not gonna make 60 frames per second, you should aim for 30 frames per second and stick to that. You might wanna add some motion blurs. I did see a really cute game once made for Firefox OS, where they had added motion blurs to all the sprites.

[00:03:19] And they had capped the frame rate to 30 frames per second, using requestAnimationFrame. And it played very smoothly, because, a lot like a movie, each one of those limited numbers of frames had a large area of motion. So the eye was able to interpret it. When we move things really fast across the screen, say at 60 frames per second, what we're hoping is that we'll move them fast enough that the eye won't be able to depict an individual picture standing alone.

[00:03:50] You may have noticed earlier, when i was trying to show the ball rolling across the screen, there was, if you look closely, there was a time where it almost looked janky. Where it was like here was the ball, and then the ball was here, and then it was here, it was moving really fast from one section to the other.

[00:04:07] When you move things over large distances really quickly, say 60 frames per second, it's gotta move from this side of the wall to that side of the wall in 300 milliseconds. You're probably going to have great big gaps of white in between those frames, as it races to the other side, there's no blur there.

[00:04:28] And this is where that 60 frames per second goal starts breaking down in large displays and yes. So, it's important to remember if you're moving something across a large space, for instance, you've got a really big display outdoors at a Cinemaplex or something, you might need to manually add motion blurs to your images to make sure that it doesn't come across janky.

[00:04:54] 60 frames per second doesn't look that great if you've got a few frames and thousands of pixels to go.
>> Rachel Nabors: Also I do wanna point out one other thing. You may have noticed that VR is coming into vogue and everyone is talking about VR in the browser. Well, it's also come to be apparent that we need to be hitting 90 frames per second for those experiences to feel realistic and performent and non-janky, it's really, really apparent in the VR head space.

[00:05:30] 60 frames per second is sort of like this arbitrary hardware/development limit that was set there because it was good enough for screens and why bother making it more efficient. Now we're seeing browser developers scramble to start hitting 90 frames per second marks. So if you think 60 frames per second is good enough, because it mimics the human eye, it doesn't.

[00:05:49] It doesn't mimic the human eye, motion blurs are closer to that. 60 frames per second is just a nice benchmark we try to get to to make ourselves feel better, but it is not the be all, end all solution to your performance woes. It's all about context and consistency.

[00:06:07] So, that said, we can still have a look at the frames per second at any given time using Chrome's Dev Tools. The instructions are on this slide. They may change in the future, because Dev Tools tend to move things around. But this frames per second meter tends to be in the same place every time.

[00:06:25] Rather than read the instructions to you, I'm gonna show you how to do it. And I'm gonna show you using my site, cuz how else would you want to investigate. It's really good too, cuz every time I get to check this out, I get to see how my performance is doing with the latest browser iteration.

[00:06:47] So, we've got our Dev Tools open, we used Cmd or Ctrl + Alt + I. Now we're gonna hit Esc to bring up the Console [SOUND]. Now in the Console, what are we gonna do? [SOUND] Rendering, there we go. We use the three little dots, if you don't already see it when a Rendering tab open, use the three little dots and look for the Rendering tab.

[00:07:11] You grab it and you're gonna check this box next to Show FPS meter. And boom, we get this lovely little meter up here which is showing us how many frames per second we have going. You might say, Rachel it's showing your site's happening at ten frames per second, that's so bad.

[00:07:26] I should remind you that right now that spinner is only happening at ten frames per second. It's very slow animation. It's not trying to run at 60 frames per second, it is literally only changing the screen 10 times a second. So that's why it looks so low. Watch what happens when I start scrolling.

[00:07:45] You'll see that the 60 frames, we start going much higher. We start seeing averages up around like 50 and 60, that's how many times the screen is being repainted per second as I'm engaging in this native scrolling animation. Now let's see what happens when I start playing with my side bar.

[00:08:09]
>> Rachel Nabors: [SOUND] Let's watch what happens to that meter. Whoosh, whoosh, whoosh, very nice, also sound effects. So that can be kind of a nice way to just see what's happening, but it's not very conclusive. And it should also be mentioned that these are browser Dev Tools, and that the very act of observing something's performance often has a performance cost.

[00:08:31] So keep that in mind as we go forward with these tools. They are not always the best way to test for performance. Sometimes you just have to run JavaScript in the background that actually checks this sort of thing. Let's try using this in some wonderful new places. Here's a little animation I did way back in the day.

[00:08:51] There is music for this, it's really cool music, but we're not gonna listen to it today, because it's so cool that it is distracting and I want you to pay attention. So you gonna hit play, and the music will start here. You can totally listen to this on your own, but for now let's open it up and go to the Rendering tab, show the frames per second meter.

[00:09:11] Let's watch what happens, cuz it's gonna start moving really fast soon, there's a beat drop in here. It's going 60 frames per second right now, this looks really good on my tricked out MacBook Pro. Just a couple of changes and then the change is gonna come. There it goes, it's going much faster now.

[00:09:26] And you might be noticing that up in the frames per second meter every once in a while it starts, yeah, that's not very smooth. Now it's trying to move everything much faster. Things are starting to get a little janky. These are all background position animations by the way.

[00:09:40] I did not make these using transforms. They ran a lot better back in the day. They don't run so great now. [SOUND] alright, alright, I'm gonna move over into Keynote. It's also fun to go to sites like CSS Awards and go to some of their favorite this won an award type sites, and check those out with the dev tools.

[00:10:01] I enjoy doing that.