How important is 60 frames per second for embedded GUI development?

There are a multitude of factors that make 60 FPS an incomplete goal. It’s not just about an arbitrary number, it’s about managing CPU workloads to achieve brilliant UX and maximum power efficiency.

When it comes to embedded GUI development, the 60 frames per second (FPS) watermark is synonymous with “smooth”, “beautiful”, and “fluid”. Developers and tech-savvy users talk about 60 FPS as the gold standard for screen updates while vendors promise that only their platforms will be the ones to help you achieve it.

When was the last time an end-user actually noticed the frame rate of their device? More likely, they complained about slow screen transitions or jittery animations and they may have attributed it to FPS without knowing the actual causes. Most users don’t care about frames per second specifically; they care about user experience (UX) and how often they need to plug in their devices.

These factors make 60 FPS an incomplete goal. It’s not just about achieving the number, it’s about managing CPU workloads without the user noticing it.

Can the human eye see 60 FPS?

There’s debate over whether we can actually tell the difference between higher frame rates. Some say that the human eye can perceive only 30 frames per second while others state that human physiology is capable of detecting up to 1000 FPS. The behavior that most agree on is best explained by these two quotes from PC Gamer:

“The first thing to understand is that we perceive different aspects of vision differently. Detecting motion is not the same as detecting light. Another thing is that different parts of the eye perform differently. The centre of your vision is good at different stuff than the periphery. And another thing is that there are natural, physical limits to what we can perceive. It takes time for the light that passes through your cornea to become information on which your brain can act, and our brains can only process that information at a certain speed.”

“The whole of what we perceive is greater than what any one element of our visual system can achieve. This point is fundamental to understanding our perception of vision.”

Consider the reason why we love 60 FPS — it’s essentially an historical artifact from many years ago. Older NTSC televisions ran at 60 Hz because it was easier to synchronize that type of video signal to the 60 Hz AC power the devices ran on. People got used to the look and feel of this frame rate and now, users expect it of every screen they interact with.

Understanding the psychology of why we want 60 FPS for our embedded devices is part of the story. The other is to consider what vendors and manufacturers do to achieve it.

Is 60 a good FPS?

More often than not, high frame rate claims are taken from applications designed to achieve an arbitrary watermark, not reflect the reality of real-world systems. Here are some examples of the design decisions made in the name of achieving 60 FPS:

1. Raw file formats used for images and animations versus the compressed formats that many developers use to save on storage space
2. Minimal inter-process communication or events handling between the backend software and the GUI
3. No complex calculations or algorithms that are usually required for applications such as maps and voice assistants
4. Use of hardware and peripherals with fast access times that aren’t necessarily available to all projects and budgets (although this is becoming less of an issue in the MCU space as silicon vendors are releasing more powerful products, like this NXP webinar explains)
5. Measurements look at the screen’s refresh rate, not the number of times the application rendered to the screen

Does refresh rate affect FPS?

The last point above is extremely important for two reasons. First, a screen running at a 60 Hz refresh rate has little to do with the application workloads put upon the CPU and GPU. The screen runs as it runs. Second, if the application is refreshing the entire framebuffer at the same rate as the screen, serious consideration must be made as to why this is so. Consuming precious processor and memory cycles should not be taken lightly, and many applications do not actually require a full-screen refresh at 60 Hz.

Is it better to have a smooth, efficient, and slick looking GUI, or is it better to make sacrifices to hit 60 FPS?

What is an acceptable FPS?

The “right” FPS for embedded applications is the one that creates the best user experience and minimizes power consumption within every frame. The best embedded UX is achieved by rendering the designer’s intent for screen elements and behavior within the boundaries of a frame. In the 60 FPS case, this means completing the necessary processing and rendering within 16 milliseconds (ms). The definition of “necessary” depends on the application but generally, this does not require the entire screen to be re-rendered every frame. As workloads consume processor cycles and power, only changing elements should be rendered.

Always ask yourself: What is required of the system and when must it be done. From there, you can tune up or down to achieve the desired FPS.

Step 1: Only render when required

Example: Rendering consumes part of frame 1 and none of frame 2

Here are two examples from the video above:

• Button up/down — if the design requires a two-state button effect, the application can render the down state in one frame and the up state in another. This requires only two frames in total.
• Animations — if a screen update only requires a 500 ms animation, an application running at 60 FPS doesn’t need to consume cycles for the whole second. It can render that element in 30 frames and either sleep or do other work for 30 frames (500 ms = half a second = 30 frames).

Step 2: Render only what’s required

Example: Render dynamic elements only

Developers have a choice as to what to update in the framebuffer: The entire screen or just the changed elements. It may seem easier to render the whole screen every frame but this requires CPU cycles and power to perform.

The clock above changes every second but only the rightmost digit changes for every nine second period. Rather than update both the static and dynamic elements every second, it’s far more efficient to update the framebuffer location that contains the rightmost digit only, saving time and CPU power.

These examples demonstrate a “minimum rendering workload” philosophy, allowing the system to perform other tasks during the frame and second, and enriching the user experience.

How Storyboard helps

Storyboard was designed to optimize CPU and GPU workloads, and maximize power efficiency. The Storyboard runtime draws and refreshes the screen only when necessary and only updates the changed elements in the framebuffer. Additionally, Storyboard includes memory visualization and performance optimization tools that let you determine the application footprint before deployment and the runtime characteristics (including FPS) on the target.

Learn more about Storyboard’s performance measurement and optimization tools in this webinar:

Performance Metrics: Actionable Resource Usage for Better Embedded GUI Performance