Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting a high-performance TV user interface using React

techblog.netflix.com

Post reply on HN
Print view View original

121–130 of 198 posts

Re: Crafting a high-performance TV user interface using React

#121

Post by makecheck »

corysama wrote: post #42
makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

At the hardware level, the author of BSNES recently wrote up an excellent rant on sources of latency in modern machines https://byuu.org/articles/latency/ But, most of what you are talking about is software latency. At 1/30th of a second each, software pipelining systems seem cheap individually but pile up very quickly. Hit a button, read the button, react in AI, react in animation, react in physics, react in graphic…

I can see the it-adds-up argument but there are also plenty of techniques to deal with that. (Maybe it is an education issue for developers.)

For instance, in a lot of cases, a human cannot reasonably observe a particular type of change on every frame so you can skip frames. What I mean is, suppose you have tasks A, B, C and D to perform “each frame”: you might be able to perform tasks A and B on odd-numbered frames and C and D on even-numbered frames, with the user no wiser, as long as the result seems fine.

Another technique is to prioritize the start and finish but not in-between. Often, intermediate frames are relatively crappy from a “niceness” or even correctness standpoint, and nobody really notices because the frames go by quickly. As long as the end frame looks as nice as possible and everything is in exactly the right place, you can get away with a lot of short-cuts for the steps taken to get there.

Re: Crafting a high-performance TV user interface using React

#122

Post by Zalastax »

rtsao wrote: post #2

For folks who really care about performance, the easiest win is just switching to Inferno or Preact. You can pretty much leave your React code unmodified and get massive performance gains.

A simple warning: switching to Inferno using inferno-compat can currently give worse performance than react. I tested this recently when Inferno 1 was released and think it's related to https://github.com/infernojs/inferno/issues/548 The techniques outlined by Netflix should apply to users of Preact and Inferno too, so it's still an interesting article.

Re: Crafting a high-performance TV user interface using React

#123

Post by usaphp »

joezydeco wrote: post #106
usaphp wrote: post #34

Earlier quoted context omitted.

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Because the software development was started 3 years ago on a platform that was spec'd out 5 years ago. Over those 5 years, the software requirements slowly crept upward while the hardware performance stayed the same and couldn't be changed.

How did the quality control passed it? The lag on some of these car infotainment system just to change the sound is abysmal, someone definely saw that and should have said something, you paying $30,000+ for something that takes 4 seconds to respond to a music volume change. Whoever is responsible for that should not work there...

Re: Crafting a high-performance TV user interface using React

#124

Post by usaphp »

kchoudhu wrote: post #94
rojoca wrote: post #86

Earlier quoted context omitted.

I found this advertisement from Mercedes interesting: https://i.redd.it/wwxk8nqh88ex.gif I can't speak for the quality of Mercedes interface (and this is obviously marketing for non-programmers) but LOC seems like an odd thing to be emphasising.

As a programmer who strongly believes in less being more, remind me to never buy a Merc.

Because some marketing guru thought that it's a great idea to advertise it that way? Common...they are great cars

Re: Crafting a high-performance TV user interface using React

#125

Post by dmsnell »

ma2rten wrote: post #97
Matthias247 wrote: post #95

Earlier quoted context omitted.

Believe it or not, the software quality in these things is often quite cruel, and even a mediocre javascript framework might perform awesome against it. I've seen enough things things like handcoded UI frameworks in C++ (in order to be fast), and then doing things like blocking network calls on the main thread from there. Some newer systems are based on QT or Android. These typically have better performance, because…

I wish there were car reviews out there that take software quality in account in particular for things like lane keep assist. When I was in the market for a car the reviews that I have seen only mention if they have the feature, not how well it actually works.

For what it's worth, there's a specific distinction for software systems like lane assist. The bar for "working" is so high that if it doesn't essentially work perfectly we can't say it works at all.

We would expect reviews to point out if a feature such as lane assist fails or has noteworthy failures (such as rapid weaving inside the lane) but maybe not so much if it works properly.

Re: Crafting a high-performance TV user interface using React

#126

Post by smallnamespace »

makecheck wrote: post #121
corysama wrote: post #42

Earlier quoted context omitted.

At the hardware level, the author of BSNES recently wrote up an excellent rant on sources of latency in modern machines https://byuu.org/articles/latency/ But, most of what you are talking about is software latency. At 1/30th of a second each, software pipelining systems seem cheap individually but pile up very quickly. Hit a button, read the button, react in AI, react in animation, react in physics, react in graphic…

I can see the it-adds-up argument but there are also plenty of techniques to deal with that. (Maybe it is an education issue for developers.) For instance, in a lot of cases, a human cannot reasonably observe a particular type of change on every frame so you can skip frames. What I mean is, suppose you have tasks A, B, C and D to perform “each frame”: you might be able to perform tasks A and B on odd-numbered frames…

> Another technique is to prioritize the start and finish but not in-between.

The problem with techniques like these is that it's almost impossible to fully generalize them (e.g. in the case of intermediate frames, if some of them are really wrong then you get sudden clipping or jumpiness).

So if your 'fast' technique only works for a certain set of parameters, then you have just introduced an implicit dependency into your system: things are fast enough while the app looks like X, but go a bit beyond that and it suddenly breaks.

Re: Crafting a high-performance TV user interface using React

#127

Post by smallnamespace »

usaphp wrote: post #123
joezydeco wrote: post #106

Earlier quoted context omitted.

Because the software development was started 3 years ago on a platform that was spec'd out 5 years ago. Over those 5 years, the software requirements slowly crept upward while the hardware performance stayed the same and couldn't be changed.

How did the quality control passed it? The lag on some of these car infotainment system just to change the sound is abysmal, someone definely saw that and should have said something, you paying $30,000+ for something that takes 4 seconds to respond to a music volume change. Whoever is responsible for that should not work there...

The quality control came last in the process, so when they 'finished' not long before the delivery date is due, QA gets a ton of political pressure to not make the date slip.

That's why test-driven design is valuable -- you iterate while testing.

Re: Crafting a high-performance TV user interface using React

#128

Post by corysama »

makecheck wrote: post #121
corysama wrote: post #42

Earlier quoted context omitted.

At the hardware level, the author of BSNES recently wrote up an excellent rant on sources of latency in modern machines https://byuu.org/articles/latency/ But, most of what you are talking about is software latency. At 1/30th of a second each, software pipelining systems seem cheap individually but pile up very quickly. Hit a button, read the button, react in AI, react in animation, react in physics, react in graphic…

I can see the it-adds-up argument but there are also plenty of techniques to deal with that. (Maybe it is an education issue for developers.) For instance, in a lot of cases, a human cannot reasonably observe a particular type of change on every frame so you can skip frames. What I mean is, suppose you have tasks A, B, C and D to perform “each frame”: you might be able to perform tasks A and B on odd-numbered frames…

In games, everything works in frames. Usually, AI, animation and physics can be completed in a single frame. But, it is very common to pipeline graphics to a separate thread that runs a frame behind everything else. The GPU frame and display frame (multiple frames on some TVs...) are pretty much impossible to eliminate.

Ideally, a game would sample input multiple times per frame, go with wide parallelism for every step (very difficult for graphics until DX12/Vulkan came along), start some GPU work before physics is completed, render in less than 1/60th of a second and the users would enable no-processing "game mode" on their lag-optimized TVs. But, that's all not common practice.

Re: Crafting a high-performance TV user interface using React

#129

Post by CamperBob2 »

Semi-OT, but does anyone know how to make the new Netflix high-performance React-based TV UI stop playing selections automatically while scrolling through them, when you pause on one for more than 3 seconds?

What possible reason(s) would they have for doing this? Doesn't initiating playback of a title cost them money for bandwidth and/or license fees? It's just plain infuriating, in a first-world-problem kind of way.

Post reply on HN