3 ms·

> but my point is that it can render smooth 144Hz animations. It can't, generally. There's a specific subset of animations that browsers can offload to the GPU

> but my point is that it can render smooth 144Hz animations. It can't, generally. There's a specific subset of animations that browsers can offload to the GPU: anything that doesn't touch the layout. So, transform/translate. That's it.

chrismorgan 5y ago
Opacity and affine transformations cover most animations that people want, though certainly not all. SVG is also generally more amenable to GPU powering. (And if they’d catch up with Firefox’s WebRender, then even more would be done on the GPU.) Beyond that, though, you’re underestimating what browsers are capable of. You’ll certainly hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank), but it’s not hard to drive layout-affecting animations at 144Hz provided you careful about isolating the affected areas. The “don’t touch layout, animate transformations” narrative that got pushed hard some years back was much more about mobile than desktop—desktop can be more efficient with transformations, but even layout-based animations will generally be smooth on desktop platforms. (In the past, Firefox struggled more than Chrome on those sorts of things, but WebRender has helped to completely reverse that.) As an absolutely toy pathological example, on my admittedly powerful laptop (Ryzen 5800HS, using integrated GPU) in Chromium (since we’re talking Electron and not WebRender), moving a series of ten inline-block 80px emojis by setting their margin-left to random layout-dependent values every frame (so that’s ten forced relayouts per frame, and quadratic layout behaviour) tends in profiling to take around 3–4ms, occasionally spiking briefly just above the 6ms budget my 165Hz display gives and causing jank (… not that I can tell visually with the emoji flickering all over the place anyway, but the profiler tells me!). For comparison, just one emoji (dodging the quadratic stuff) tends to take around 1ms, showing that a lot of the costs here are constant. URL for the code: data:text/html;charset=utf-8,<style>body{overflow:hidden}div{display:inline-block;left:0;position:relative;font-size:5em}</style><div>%F0%9F%99%82</div><div>%F0%9F%99%81</div><div>%F0%9F%A4%A8</div><div>%F0%9F%98%AE</div><div>%F0%9F%98%9B</div><div>%F0%9F%98%80</div><div>%F0%9F%98%86</div><div>%F0%9F%98%A2</div><div>%F0%9F%98%95</div><div>%F0%9F%98%92</div><script>function f(){document.querySelectorAll('div').forEach(e=>e.style.marginLeft=Math.random()*(innerWidth-e.offsetWidth-e.offsetLeft*0.1)+'px');requestAnimationFrame(f)}requestAnimationFrame(f)</script>
- dmitriid 5y ago
  > it’s not hard to drive layout-affecting animations at 144Hz provided And you've literally written how hard it is: "hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank)" and then you couldn't reliably animate 10 emojis. Ten. Ten. And you call animating ten emojis a pathological case.
  - chrismorgan 5y ago
    I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame, and that there’s a quadratic path in the layout involved, being done ten levels deep. Neither of these are realistic: an even vaguely sensible approach will not force style recalculation or layout during the callback at all, and trigger no quadratic layout path. Also in cases where you do need to animate something that’s part of the layout (not particularly common, by the way), it’s decidedly rare to want to animate more than one or perhaps two such element at a time—ten is massive overkill for the sort of thing we’re talking about (general-purpose desktop software). And alternatives to the web are normally not actually going to be better—the web has had an insane amount of effort put into making something not particularly amenable to good performance faster than it has any right to be, so that it tends to be able to outperform the theoretically potentially superior, even if it sometimes requires some care to achieve that. (By this, I mean to intimate the vague idea that by using a browser you’re not painting yourself into a corner where it’s simply impossible to get good performance without rewriting from the ground up, which is absolutely a problem with mainstream desktop GUI frameworks.) Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) or forced recalculations (as you should be doing) and you’re back down to mostly just over 1ms. A hundred elements is then normally 2.5–3ms, with occasional brief spikes of 6–7ms (the spikes at this point are larger proportionally to the baseline than in the pathological ten case). And to remind you, this is for animating a comparatively large number of decent-sized independent elements in the most expensive way possible. It’s significantly more complex than a realistic UI animation test, though certainly a far cry from what is possible in something designed for the purpose, or even Firefox thanks to WebRender: it’s still comfortably hitting over 100fps at a thousand of these emoji, including all this layout recalculation—change a non-layout property instead and it can go way further. (Meanwhile, I try pasting my thousand-element 23KB data: URI into Chromium, and it completely locks up, and killing the process is my only recourse.)

chrismorgan 5y ago

Opacity and affine transformations cover most animations that people want, though certainly not all. SVG is also generally more amenable to GPU powering. (And if they’d catch up with Firefox’s WebRender, then even more would be done on the GPU.) Beyond that, though, you’re underestimating what browsers are capable of. You’ll certainly hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank), but it’s not hard to drive layout-affecting animations at 144Hz provided you careful about isolating the affected areas. The “don’t touch layout, animate transformations” narrative that got pushed hard some years back was much more about mobile than desktop—desktop can be more efficient with transformations, but even layout-based animations will generally be smooth on desktop platforms. (In the past, Firefox struggled more than Chrome on those sorts of things, but WebRender has helped to completely reverse that.) As an absolutely toy pathological example, on my admittedly powerful laptop (Ryzen 5800HS, using integrated GPU) in Chromium (since we’re talking Electron and not WebRender), moving a series of ten inline-block 80px emojis by setting their margin-left to random layout-dependent values every frame (so that’s ten forced relayouts per frame, and quadratic layout behaviour) tends in profiling to take around 3–4ms, occasionally spiking briefly just above the 6ms budget my 165Hz display gives and causing jank (… not that I can tell visually with the emoji flickering all over the place anyway, but the profiler tells me!). For comparison, just one emoji (dodging the quadratic stuff) tends to take around 1ms, showing that a lot of the costs here are constant. URL for the code: data:text/html;charset=utf-8,<style>body{overflow:hidden}div{display:inline-block;left:0;position:relative;font-size:5em}</style><div>%F0%9F%99%82</div><div>%F0%9F%99%81</div><div>%F0%9F%A4%A8</div><div>%F0%9F%98%AE</div><div>%F0%9F%98%9B</div><div>%F0%9F%98%80</div><div>%F0%9F%98%86</div><div>%F0%9F%98%A2</div><div>%F0%9F%98%95</div><div>%F0%9F%98%92</div><script>function f(){document.querySelectorAll('div').forEach(e=>e.style.marginLeft=Math.random()*(innerWidth-e.offsetWidth-e.offsetLeft*0.1)+'px');requestAnimationFrame(f)}requestAnimationFrame(f)</script>

dmitriid 5y ago
> it’s not hard to drive layout-affecting animations at 144Hz provided And you've literally written how hard it is: "hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank)" and then you couldn't reliably animate 10 emojis. Ten. Ten. And you call animating ten emojis a pathological case.
- chrismorgan 5y ago
  I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame, and that there’s a quadratic path in the layout involved, being done ten levels deep. Neither of these are realistic: an even vaguely sensible approach will not force style recalculation or layout during the callback at all, and trigger no quadratic layout path. Also in cases where you do need to animate something that’s part of the layout (not particularly common, by the way), it’s decidedly rare to want to animate more than one or perhaps two such element at a time—ten is massive overkill for the sort of thing we’re talking about (general-purpose desktop software). And alternatives to the web are normally not actually going to be better—the web has had an insane amount of effort put into making something not particularly amenable to good performance faster than it has any right to be, so that it tends to be able to outperform the theoretically potentially superior, even if it sometimes requires some care to achieve that. (By this, I mean to intimate the vague idea that by using a browser you’re not painting yourself into a corner where it’s simply impossible to get good performance without rewriting from the ground up, which is absolutely a problem with mainstream desktop GUI frameworks.) Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) or forced recalculations (as you should be doing) and you’re back down to mostly just over 1ms. A hundred elements is then normally 2.5–3ms, with occasional brief spikes of 6–7ms (the spikes at this point are larger proportionally to the baseline than in the pathological ten case). And to remind you, this is for animating a comparatively large number of decent-sized independent elements in the most expensive way possible. It’s significantly more complex than a realistic UI animation test, though certainly a far cry from what is possible in something designed for the purpose, or even Firefox thanks to WebRender: it’s still comfortably hitting over 100fps at a thousand of these emoji, including all this layout recalculation—change a non-layout property instead and it can go way further. (Meanwhile, I try pasting my thousand-element 23KB data: URI into Chromium, and it completely locks up, and killing the process is my only recourse.)