The function is triggered with the “requestAnimationFrame” method. (Since browser compatibility has dramatically improved in the last few years… http://caniuse.com/#feat=requestanimationframe …I now feel comfortable using this method.) When a new frame is ready to be drawn, a function can be run. The “calculating” function runs itself with the requestAnimationFrame(calculating) line, This cause a loop, which continues indefinitely.
The function doesn’t launch itself though, which is a job for the following line…
22 | calculating(); |
The FPS value is displayed onscreen with an element. The ID for this element is “fps-text”. Again, you don’t have to use the same name. The point is that a unique element ID is needed. The inner HTML code is replaced with the value of the “fps” variable.
By displaying text in this manner, the value changes too quickly to be easily legible. The problem is clear – the difference between the frames is not always the same number. Actually, it’s changes frequently. There are many ways to solve this problem. Here’s the way shown in the template…
24 25 26 | setInterval(function(){ hypeDocument.setElementProperty(Needle, 'rotateZ', (fps*3)-180, 0.25); }, 500); |
This is skeuomorphism. Like a fuel gauge in a classic car, a “Needle” element will rotate based on the fps value. There are two ways this normalizes the FPS value. A “setInterval” with a 500 millisecond delay slows things down. But also, by using the Hype “set” JavaScript API, the transition can be animated. With the “easein” timing function, the needle slowly moves towards the new FPS number. This keeps the gauge from flickering back and forth.
Even if you’re not into game development, this is a neat way to animate the display of data.
While this is not perfect, as the gauge doesn’t do a good job of displaying low frame rates, it is an easy way to highlight problems with your project. If the needle is below the halfway mark, there’s a problem with performance. The FPS is way too low. Like many web development projects, this problem has multiple issues. In addition to the difficulty of getting the most accurate value, the FPS code should be lightweight. Otherwise, the FPS value recorded is skewed.
A possible solution is presented in Part II of this project. But here, I’m going to leave it unsolved. That’s a great way for you to learn. How would you improve upon this project?
Anyway, here’s a download link to the FPS Hype Template.
Even if JavaScript is something that makes you break out with night terrors, the template can be useful for performance testing. How do gradients affect animation? If all of the circle elements use solid colors instead of gradients, is the Physics based animation smoother or basically same? What happens to the FPS value when the elements stop moving? What happens to the FPS value when an element is dragged across the screen? How is the animation on mobile vs. desktops? By adding, removing or changing the test elements, you can better learn about how Hype works. This knowledge can lead to much better looking projects.