- From: Kyle Simpson <getify@gmail.com>
- Date: Fri, 8 Jul 2011 10:52:28 -0400
- To: <robert@ocallahan.org>, Sigbjørn Vik <sigbjorn@opera.com>
- Cc: <public-web-perf@w3.org>, "Andrew Dupont" <w3@andrewdupont.net>
> My main worry is that you can only really discover whether or not you can > play the animation by actually trying to play it. But starting to play it, > then suddenly turning it off, is likely to not be acceptable. If we expose the current average FPS to JavaScript, then responsible animation libs (like Scripty2) can monitor that value throughout the lifetime of the page to try and make the best balanced decisions about how to run animations... For instance, if a user requests a taxing animation A, and it is caused to start running, and while it's running, animation B is requested... then the lib could see that the FPS is lower than the acceptable threshold, and so for B, use a different approach... whereas if either A or B is requested by itself, the FPS may in fact be acceptable enough. Bottom line, exposing the running average of FPS to the page allows a responsible lib to tailor the behavior to the running conditions of the page, accepting that such conditions may go up and down, and that the lib should be able to detect such things. With that in mind, I don't think a one-time check like a media-query is sufficient. But perhaps it might be if that media-query is re-evaluated each time it's requested -- not sure if that's how media-queries work or not. I will say this, though... the point of this request is that a lib can decide if a CSS animation is sufficient, or if it should pick a fallback, like JS animation... so there'd have to be some way to programmatically decide that the media-query failed, so that the lib could substitute a different approach. --Kyle
Received on Friday, 8 July 2011 14:53:00 UTC