4 ms·

> 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

> 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.)
- dmitriid 5y ago
  > I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame It's only pathological because the web makes it pathological. Phones routinely do complex layout animations that are unimaginable on the web. And yet, "we're doing layout calculations on ten emojis, it's pathological" is the norm on the web. > t’s decidedly rare to want to animate more than one or perhaps two such element at a time Yes. It's rare on the web. Because the web is unbelievably inefficient and slow when it comes to any animations beyond a very limited subset. > 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 I have no idea where this verifiably false mindset comes from. Anyone you ask is "yes, the web is very performant, you can't do better, the alternatives can't be better". And yet you use apps, and frameworks, and approaches that are magnitudes faster, more performant, and create significantly more complex interactions and layouts than the web could ever hope to achieve. Yes. I'm talking about your phone. I'm talking about your desktop. Right now my iPhone screen with two notifications displays more animations, at a smoother framerate than your "pathological example". The supercomputers in our pockets and on our desks can output this: https://www.youtube.com/watch?v=EFyWEMe27Dw https://www.youtube.com/watch?v=EFyWEMe27Dw And yet, "it's rare to animate more than two things, other cases are pathological, I doubt anything else can perform better". You're talking about performance available to 1984 Macintosh https://www.youtube.com/watch?v=2B-XwPjn9YY https://www.youtube.com/watch?v=2B-XwPjn9YY > Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) Ah yes. The usual case. That's why it's still impossible to animate height: auto, or an item being removed from a list without complex hacks because on the web everything simple is hard beyond all reasoning, and everything hard is impossible.

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.)

dmitriid 5y ago
> I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame It's only pathological because the web makes it pathological. Phones routinely do complex layout animations that are unimaginable on the web. And yet, "we're doing layout calculations on ten emojis, it's pathological" is the norm on the web. > t’s decidedly rare to want to animate more than one or perhaps two such element at a time Yes. It's rare on the web. Because the web is unbelievably inefficient and slow when it comes to any animations beyond a very limited subset. > 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 I have no idea where this verifiably false mindset comes from. Anyone you ask is "yes, the web is very performant, you can't do better, the alternatives can't be better". And yet you use apps, and frameworks, and approaches that are magnitudes faster, more performant, and create significantly more complex interactions and layouts than the web could ever hope to achieve. Yes. I'm talking about your phone. I'm talking about your desktop. Right now my iPhone screen with two notifications displays more animations, at a smoother framerate than your "pathological example". The supercomputers in our pockets and on our desks can output this: https://www.youtube.com/watch?v=EFyWEMe27Dw https://www.youtube.com/watch?v=EFyWEMe27Dw And yet, "it's rare to animate more than two things, other cases are pathological, I doubt anything else can perform better". You're talking about performance available to 1984 Macintosh https://www.youtube.com/watch?v=2B-XwPjn9YY https://www.youtube.com/watch?v=2B-XwPjn9YY > Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) Ah yes. The usual case. That's why it's still impossible to animate height: auto, or an item being removed from a list without complex hacks because on the web everything simple is hard beyond all reasoning, and everything hard is impossible.