Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Smooth Animations for Web & Hybrid

213 views

Published on

Presented at Web Unleashed 2017. More info at www.fitc.ca/webu

Presented by Alexander Blom, Isle of Code

Overview

Adding animations to web and hybrid apps can be challenging. Aside from choosing technique, you are often left with jank and less than desirable performance.

Objective

Audience members will leave with a better understanding of animation performance & pitfalls desktop and mobile context.

Target Audience

Web/Hybrid developers looking to improve animation performance.

Assumed Audience Knowledge

Basic JS/CSS assumed

Six Things Audience Members Will Learn

What are my choices when needing to animate?
What changes in a mobile context?
What are the tradeoffs and how do I decide?
What are the common pitfalls?
How do I debug performance problems?
Getting a smooth animation.

Published in: Design
  • Be the first to comment

  • Be the first to like this

Smooth Animations for Web & Hybrid

  1. 1. Animations for Web & Hybrid @alexblom Isle of Code
  2. 2. whoami
  3. 3. Isle of Code • Toronto + Houston based development; • Focused on Ember/Vue/React/Cordova; • Creators of ember-cordova & corber;
  4. 4. corber.io • Extension of ember-cordova; • Supports Ember, Vue, React, Glimmer; • CLI for framework -> hybrid builds; • Adds livereload, unified builds, splash/icons, etc;
  5. 5. corber demo
  6. 6. Contents • What makes a good animation?; • Profiling / performance; • 3 examples; • Additional options (promoting layers, JS animation API);
  7. 7. What makes a good animation?
  8. 8. FPS Target • 60fps is considered best; • 1000ms / 60fps = ~16.6ms per frame; • 60fps is not always achievable!; • It is better to deliver a consistent frame rate than a variable one. Consider targeting 30fps;
  9. 9. Animation Options • Declarative: CSS; • Generally speaking most performant; • Browser knows what is happening up front - can save you from yourself; • Can become complex to write;
  10. 10. Animation Options • Imperative: JS; • Tell the browser how. Easier to spell out in code (e.g. bounce); • Run on the main thread (not great); • requestAnimationFrame & webAnimationsAPI can fix performance issues - to be discussed later;
  11. 11. Profiling / Performance
  12. 12. From 0 to rendered
  13. 13. How our content is rendered • 1: DOM Tree constructed; • 2: Layout (recursively from the top left); • highly interdependent; • expensive;
  14. 14. Layout Styles width overflow/overflow-y min-width font-weight height font-size min-height text-align padding line-height display vertical-align border white-space border-width clear position bottom/top/left/right float
  15. 15. Reflow
  16. 16. What causes Reflow? • Resizing the browser window; • using JavaScript methods involving computed styles; • adding or removing elements from the DOM; and • changing an element's classes. • https://developers.google.com/speed/articles/ reflow
  17. 17. How our content is rendered • 1: DOM Tree constructed; • 2: Layout (recursively from the top left); • 3: Paint;
  18. 18. Paint Styles border-style outline border-radius outline-color background outline-width background-size outline-style background-image color background-repeat visibility background-position text-decoration box-shadow
  19. 19. Paint Styles • opacity is a special case; • If the element has its own layer, this is handled automagically by lowering the alpha-mask value;
  20. 20. How our content is rendered • 1: DOM Tree constructed; • 2: Layout (recursively from the top left); • 3: Paint; • 4: Composite/Layering (default is a single layer);
  21. 21. Layers • Default is a single layer; • Composed layer more efficient to animate - GPU; • Pushing every node to it’s own layer is the worst case; • The most performant is hardware accelerated properties on composite layers (e.g. transform/ translateX); • Layers are expensive (width * height * 3);
  22. 22. Promoting a Layer • will-change property, e.g.; • will-change: auto; • will-change: scroll; • will-change: transform;
  23. 23. Prior Layers
  24. 24. Add will-change;
  25. 25. Layers
  26. 26. Layout Thrashing
  27. 27. Layout Thrashing
  28. 28. Profiler Tool
  29. 29. Profiler Tool
  30. 30. Profiler Tool
  31. 31. Profiler Tool
  32. 32. Profiler Tool
  33. 33. Our Scene https://www.sitepoint.com/playing-with-fire-organic-css3-animation/
  34. 34. Animation 1 - The worst case
  35. 35. Animation 1
  36. 36. Animation 1
  37. 37. Some of our problems • Big FPS dip; • Each animation is triggering a reflow; • We are not taking advantage of hardware- accelerated properties; • We are redrawing at a fixed (but not) rate; • Will keep running in an unfocused tab;
  38. 38. We are redrawing at a fixed rate • Sort of: • interval timing is not guaranteed - if our thread is busy it will take longer; • When a tab is inactive the interval will still fire every ~1s;
  39. 39. CSS3 Animations (@keyframe)
  40. 40. https://www.sitepoint.com/playing-with-fire-organic-css3-animation/
  41. 41. CSS3 Animation • animation-duration; • animation-delay; • animation-timing; • ease, linear, ease-in, ease-out, ease-in-out, cubic-bezier;
  42. 42. Why don’t we try them in this case?
  43. 43. But CSS animations are hard!
  44. 44. Animation API
  45. 45. Animation 2 - Hardware Accelerated
  46. 46. http://slides.com/ehayman/deck-1#/6
  47. 47. http://slides.com/ehayman/deck-1#/6
  48. 48. Animation 2
  49. 49. Timeline
  50. 50. Profile • 6248ms to 5420ms on scripting; • 10588ms to 4818ms rendering; • 267ms to 1488ms painting;
  51. 51. Some of our problems • Big FPS dip (sort of); • Each animation is triggering a reflow; • We are not taking advantage of hardware- accelerated properties; • Will keep running in an unfocused tab; • We are redrawing at a fixed rate;
  52. 52. Animation Frames
  53. 53. animationFrame • Supported for major browsers; • Only draws when: • the animation will be visible; • the browser is ready; • there are no other frames waiting to be drawn; • Eliminates unnecessary draws & overloaded callbacks;
  54. 54. animationFrame
  55. 55. animationFrame
  56. 56. Profile • 5420ms to 2605ms on scripting; • 4818ms to 5295ms rendering; • 1488 to1557ms painting;
  57. 57. Some of our problems • Big FPS dip; • Each animation is triggering a reflow; • We are not taking advantage of hardware- accelerated properties; • This will keep running in an unfocused tab; • We are redrawing at a fixed rate;
  58. 58. Still could be better • Immediate reaction may be to tear down unused elements; • Don’t
  59. 59. Demo
  60. 60. Profile • 2605ms to 1068ms on scripting; • 5295ms to 2100ms rendering; • 1557 to 702ms painting;
  61. 61. Intersection Observer API
  62. 62. Intersection Observer API • “The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s.” • https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
  63. 63. Intersection Observer API
  64. 64. Intersection Observer API • callback function receives a list of intersections detected;
  65. 65. Passive Event Listener
  66. 66. Passive Event Listener • Allows you to indicate preventDefault will not be used - e.g. eliminates block on scroll
  67. 67. My best practices • Avoiding JS Animation API until better Safari support; • Pages with smaller animations (e.g. button bounce): • CSS/Hardware accelerated animations are fine; • Will generally promote frequent/transitional animations to their own layer; • Pages with lots of animations: • Just use animationFrame;
  68. 68. Animations for Web & Hybrid @alexblom Isle of Code

×