[mediaqueries] media query for relative animation performance

[jcayzac]

(update: fast) covers a whole spectrum of relative sluggishness. A low-end smartphone in battery-saving mode is incapable of executing large CSS animations or cross-page transitions other than fade-in/fade-out in a way that does not negatively impact its end user's experience.

Yet, there is currently no way for web developers to detect this and dial animations down.

What could be done to solve this?

1. A (refresh-rate:) media query requiring a minimal number of FPS would probably not work, due to refresh rates being variable nowadays and the idle refresh rate probably kept low in the absence of any scrolling or animating. One way it could work would be by matching by default, but not match for a period after the refresh rate during scrolling or animating has dropped below the threshold, still.
2. An aggregate measure of the recent rendering smoothness and CPU load could be exposed to provide some performance grade, and a new media query made to match only if a certain grade is met.
3. More ideas welcome!

[frivoal]

The primary motivation for update: fast vs update: slow was not intended to distinguish between "normal" devises with good or mediocre performance, but with entirely different categories of devices: phone (low or high end) vs e-ink reader, or things so underpowered that even with a good screen, they're hardly faster than an e-ink device. Not so much "how smooth are your animations?", and more "Can you animate at all? If you can't animate, are you a piece of paper (none), or are you at least capable of changing what's on the screen at all once rendered, even if it's going to take a while?"

At the very low end of performance, it is true that there's quite a bit of a gray zone at the frontier between slow animations, and "you call that an animation? I barely got 2 frames between the start and end of this transition…"

The problem is, this is quite subjective. Do you draw the line at 1fps? 5fps? 15fps? Anything lower than 60fps? It could be nice to leave the choice to developers, give them a refresh-rate query, but I don't think that's feasible. The frame rate can heavily depend on the content in addition to the device; there's not even a requirement that the UA must update the whole screen at once, so different parts of the screen could be refreshing at different rates…

I wonder if we just need one more level:

• cannot change at all. e.g.: paper
• can update, but not meaningfully animate, even for simple pages. Measuring "reload time" (maybe a few 100 ms to a few s) makes more sense than measuring fps. e.g.: classic e-ink, severely underpowered devices (think embedded controller, not low-end smart-phone)
• can animate, but not well. Maybe up to something like 10fps
• Can animate smoothly

[Crissov]

Also see #12654

[jcayzac]

@frivoal @Crissov I agree that maybe we're just missing one level. Between Florian's comment and the comment on the linked issue, it seems we're either missing a smooth above fast or something that people would call slow but above slow (the latter actually meaning "semi-static" per current specs).

Given the current meaning of fast, for backward compatibility, I'd lean toward the former.

It seems I botched my issue search before I created this one. Let's close it and continue on #12654. thanks @Crissov for the link!