- From: James Robinson <jamesr@google.com>
- Date: Tue, 26 Jul 2011 22:46:43 -0700
- To: public-web-perf@w3.org
- Message-ID: <CAD73mdLjMu5UyKQ9g3NgAWMP871LUTLM77jrAYszYwpQHGz4+w@mail.gmail.com>
Here's a quick update on the remaining open issues for request animation frame and the next steps for them ( http://www.w3.org/2010/webperf/track/issues/raised): ISSUE-2 and ISSUE-3 are about the value of the callback's timestamp and its interaction with callback scheduling. I think that the best way to resolve these issues is to have a standardized monotonic time source define for the web platform as a whole and then refer to it from the request animation frame specification. I floated a proposal on the WHATWG list a few weeks ago to attract some broader feedback: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032343.html. I encourage any of you who are interested in this issue to chime in. This proposal hasn't solidified yet into something completely concrete, but I'm hopeful that it will soon work its way into HTML as something we can depend on. ISSUE-4 is about having an element parameter to allow the user agent to avoid invoking callbacks that would update animations for fully offscreen content within an otherwise visible document. Previous discussions about this stalled out when trying to pin down the exact order in which visibility was determined and the callbacks were fired. One possibility is to do this visibility calculation after invoking each callback, to try to invoke as few callbacks as possible on pages where a side effect of one callback is to change the visibility of another. This can minimize the number of times the user agent calls into script at the cost of potentially updating calculated style and layout many times. Another possibility is to perform the visibility calculation as few times as possible and invoke all callbacks associated with visible elements en masse. This may result in invoking callbacks for elements that have been made not visible by earlier callbacks in exchange for minimizing the number of times the user agent has to update style and layout. The approach that is chosen has an author-visible impact in that it changes the order of callbacks. We haven't implemented anything sophisticated to determine element visibility in WebKit, although I'd still like to do so at some point. There are significant potential gains from having this data, but also potential for author misuse and confusion. At this point I'm inclined to leave the issue open for now. - James
Received on Wednesday, 27 July 2011 05:47:07 UTC