Successfully reported this slideshow.

Netflix Webkit-Based UI for TV Devices

101,706 views

Published on

Slide deck for a presentation at OSCON 2011 about why Netflix uses web technology for TV user interfaces and how we maximize performance for a broad range of devices.

Published in: Technology

Netflix Webkit-Based UI for TV Devices

  1. Netflix Webkit-Based UIfor TV Devices<br />Matt McCarthy & Kim Trott<br />NetflixJuly 29, 2011<br />
  2. These slides were originally designed for a presentation. They’ll make much more sense if you read the speaker notes.<br />(On Slideshare, as of 8/11, speaker notes appear beneath the slide show.)<br />README<br />
  3. What is Webkit TV UI?<br />Why web?<br />Engineering for UI variation<br />Performance for TV devices<br />Topics<br />
  4. Webkit TV UI<br />what’s the big deal?<br />
  5. 2’ UI vs. 10’ UI<br />2’ UI<br />10’ UI<br />
  6. Some Netflix Webkit TV UI devices<br />…and many more<br />
  7. User Agent<br />I’m an open web.<br />I’m a WebKit.<br />
  8. Why Web?<br />we did think this through<br />
  9. Dynamic Updates<br />
  10. Common Technology<br />
  11. Dynamically Add Locale Support<br />
  12. A/B Testing<br />
  13. How we support vast variation<br />not just “very carefully”<br />
  14. Example: “Special” UI<br />
  15. Which component handles the next keystroke?<br />How & where do we model navigation between components?<br />…And also, these components should be reusable between completely different UIs<br />Solve These<br />
  16. Tight coupling<br />Mediator pattern<br />DOM focus & events<br />Solutions We’ve Tried & Abandoned<br />
  17. States as the C in MVC<br />Can drive state transitions<br />States are event handling contexts<br />User input<br />Programmatic events<br />Current Solution: State Transition System<br />
  18. Search Input<br />State<br />Search Input<br />State<br />Search Compound<br />State<br />Search Results<br />State<br />
  19. Search Input<br />State<br />Search Compound<br />State<br />Search Results<br />State<br />Search Results<br />State<br />
  20. Events<br />Dependency injection<br />Loose Coupling<br />
  21. PERFORMANCE AND MEMORY<br />building a lean, mean content browsing machine<br />
  22. Single-page, long-lived application<br />High volume of data & images<br />Require high performance<br />Range of device capabilities<br />Why do we worry?<br />
  23. Device Ecosystem<br />Video Memory<br />CPU<br />GPU<br />Main Memory<br />CPU Architecture<br />Graphics driver<br />Network stack<br />Memory bus speed<br />
  24. Device Ecosystem<br />CPU: 3.2 GHz<br />GPU: 550 MHz<br />Memory: 512 MB<br />CPU: 600 MHz  3.2 GHz<br />Memory: 88 MB  512 MB<br />
  25. Memory Budget<br />Total Memory<br /><ul><li>Operating System
  26. Webkit
  27. Netflix SDK
  28. Network/Video Buffer</li></ul>UI Budget<br />
  29. Progressive enhancement<br />Baseline<br />Enhanced<br />Animations<br />Request throttling<br />Cache sizes<br />Data pre-fetching<br />None enabled<br />5 concurrent<br />Small<br />Delayed,<br />Small batches<br />All enabled<br />20 concurrent<br />Large<br />Frequent,<br />Larger batches<br />
  30. 0.1 second: Feeling of instantaneous response<br />1.0 second: Keeps flow of thought seamless<br />10 seconds:Keeps the user’s attention<br />Perceived Performance<br />Nielsen 2010, 1993; Miller 1968; Card et al. 1991<br />
  31. Provide immediate feedback on user input<br />Split up long running process<br />Mask and reduce perceived wait times<br />Background work and anticipate common requests<br />Ways to Improve Responsiveness<br />
  32. Wait until the user settles for expensive operations or paints<br />Avoid DOM changes at the beginning of / during animations<br />Tune delays to find the sweet spot<br />Ways to Improve Responsiveness<br />
  33. Provide Visual Cues<br />
  34. Naïve implementation<br />Progressively inserted new DOM nodes<br />Animated very large DOM parent<br />Height ever-growing of DOM parent<br />Bad: Performance degraded as you scrolled<br />1<br />2<br />3<br />4<br />5<br />6<br />7<br />Performance Evolution: Scrolling Rows<br />
  35. Naïve implementation<br />Progressively inserted new DOM nodes<br />Animated very large DOM parent<br />Height ever-growing of DOM parent<br />Bad: Performance degraded as you scrolled<br />1<br />2<br />3<br />4<br />5<br />6<br />7<br />Performance Evolution: Scrolling Rows<br />
  36. Optimized implementation<br />Recycle DOM nodes<br />Animate each row individually<br />Delaying modifying row until comes into viewport or the user settles<br />Good: Performance consistent regardless of location<br />1<br />2<br />3<br />4<br />2<br />1<br />5<br />Performance Evolution: Scrolling Rows<br />
  37. Optimized implementation<br />Recycle DOM nodes<br />Animate each row individually<br />Delaying modifying row until comes into viewport or the user settles<br />Good: Performance consistent regardless of location<br />3<br />4<br />5<br />1<br />2<br />Performance Evolution: Scrolling Rows<br />
  38. Software (CPU) = slowerHardware (GPU) = faster<br />
  39. Avoid CSS gradients, boxshot shadows<br />Use images instead<br />Example: Full-screen CSS radial gradient<br />Paints were 13 times faster without it<br />CSS = SoftwareImage = Hardware<br />
  40. Eliminate paints<br />
  41. Enables GPU acceleration of compositing parts of the page<br />Greatly benefits CSS animations<br />Accelerated Compositing<br />
  42. DOM Tree -> Render Tree -> RenderLayer Tree<br />Software path<br />Changes to a render layer require repainting all overlapping layers<br />Hardware path<br />Some render layers paint to their own backing surface (compositing layer)<br />Changes to a layer only repaint the contents of that layer<br />Accelerated Compositing<br />
  43. 3D transforms<br />Opacity changes<br />Accidental<br />Overlapping a layer<br />Render engine<br />Several ways to create layers<br />
  44. Safe CSS properties<br />Transforms<br />Opacity<br />Un-safe<br />Any other CSS properties<br />DOM manipulation<br />Leveraging layers<br />
  45. Keep layers small<br />Don’t inadvertently create gigantic layers<br />Memory consumption = width x height x 4 (bit depth)<br />Animate smaller areas rather than large parts of the screen<br />Trial and error, testing important<br />Tips<br />
  46. Show Compositing Borders<br />
  47. Avoid unbounded growth<br />Minimize the number of throwaway objects<br />Use closures sparingly & only where necessary<br />Dynamically load and unload code<br />Memory<br />
  48. What’s Next?<br />i was led to believe there would be flying cars<br />
  49. Questions?<br />Matt McCarthy – @dnl2ba<br />Kim Trott – @ktrott00<br />

×