W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

[RequestAnimationFrame] Summary of open issue status

From: James Robinson <jamesr@google.com>
Date: Tue, 26 Jul 2011 22:46:43 -0700
Message-ID: <CAD73mdLjMu5UyKQ9g3NgAWMP871LUTLM77jrAYszYwpQHGz4+w@mail.gmail.com>
To: public-web-perf@w3.org
Here's a quick update on the remaining open issues for request animation
frame and the next steps for them (

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:
 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:08 UTC