Jump to content

Search In
  • More options...
Find results that contain...
Find results in...


  • Posts

  • Joined

  • Last visited

paul_irish's Achievements


Newbie (1/14)



  1. FPS Counter ~= Main Thread performance. Gotcha. Yeah makes sense. We've been discussing having idle/cpu time available in the Frame Timing API for similar reasons. Benchmark composition I misspoke on independently controlling the transform components. I now understand that independent transform control was a requirement of these tests from the start, but that wasn't clear from your tests as they were very much focused on main thread utilization and FPS. But yes, the poor performance of the CSS animations are direct downstream effects of the element nesting. To me, the big summary is this: If you need independent transform control, JS is going to have a significant win as your element count will balloon with a CSS-only approach. If you don't need that, performance will be comparable (assuming ideal implementations of both).
  2. Hi Jack! I'm a fan of GSAP and recommend it for many cases, but unfortunately a few things indicated in this video are not accurate. Because there was so much detail in the video, I'm going to handle things one by one. Task Manager. You only got to show the Browser process and not the Tab's own renderer process (or the GPU). Your results make sense because the browser takes over handling much of the animation instead of locking up the main thread. When you consider the other processes the numbers between the two approaches are fairly equivalent. FPS counter. This is tricky because we're relying on a FPS counter implemented in JS that runs on the main thread, but what we care about is how often pixels are drawn to the screen. Since compositor frames are distinct from main-thread frames, rAF cannot measure the performance of any CSS animations. (The Frame Timing API will solve this). I would recommend using the FPS counter in the Rendering tab of DevTools. Timeline not showing costs for CSS animation. Yeah, that's a pretty good bug. Try in Canary, as things look good there. You'll see heavy Recalc Style operations on the main thread . Synchronization. This is a great demonstration of what happens when you have compositor and main thread animations running concurrently on the same element AND you consistently blow your frame budget on one of the the threads. That sort of thing doesn't happen too often in practice, but it's something we keep an eye out for. Animating elem.style.top. You and I both know that 1) animating the top property isn't a performant choice and 2) top positions cannot be sub-pixel, so they are always fit to an integer. That just leads to jaggier animations in comparison to a transform. In your demo, however, neither of these really are the determining factor, but it's more of an exacerbation of the issue described next… This is an unfair benchmark. (You noticed this after you finished the video, but.. there it is.) In the CSS variant, there are FIVE divs representing each red box. In your GSAP variant, just one. This difference has a huge effect on the numbers; DOM size blows out Recalc Style costs quickly. You don't necessarily need five divs per box for CSS, though I'll admit it's not entirely elegant to handle the animations independently with only a single element and single keyframe animation definition. Regardless, it's doable. I've (quickly) redone the CSS bits to use a single element and encourage you to look at the results: http://codepen.io/paulirish/full/9712e8fb6a451e0ee7393d01e7f59f53/ Now that both variants use just one element per box, the performance between the two is completely comparable. Try the translate+scale+rotate or translate+top. No significant difference between CSS & GSAP. ... Ultimately for this benchmark, CSS and GSAP perform basically the same. GSAP has advantages for authoring and manipulating different transform properties independently, and CSS's advantage is that it's a fraction of the bytes necessary. I still recommend GSAP for ultimate control and authoring experience; it can handle some really ambitious animation asks and it's easily best-in-class.