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

Re: [RequestAnimationFrame] Processing model defined

From: Paul Bakaus <pbakaus@zynga.com>
Date: Thu, 25 Aug 2011 03:37:33 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>, James Robinson <jamesr@google.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>, John Resig <jeresig@gmail.com>
Message-ID: <CA7BF15E.D156%pbakaus@zynga.com>
Hi Boris,

Happy to help wherever I can. While I'm not actively involved in the
jQuery project any more, I can help with reviewing animation proposals. I
started jQuery UI and wrote the animation extensions for it.

For the current implementation of animate(), I've cc'ed John Resig. John,
do you see a feasible way of "upgrading" animate() to use


Am 24.08.11 07:13 schrieb "Boris Zbarsky" unter <bzbarsky@MIT.EDU>:

>On 8/17/11 2:22 AM, James Robinson wrote:
>> On Wed, Jul 27, 2011 at 11:13 PM, Boris Zbarsky <bzbarsky@mit.edu
>> <mailto:bzbarsky@mit.edu>> wrote:
>>     Or put another way, we _do_ want jQuery to build animate() on top of
>>     requestAnimationFrame and we do _not_ want to break the huge amount
>>     of deployed content that's using animate() and was perfectly fine
>>     with the behavior it used to have.  The question is how animate()
>>     can implement the behavior it used to have on top of
>>     requestAnimationFrame.
>> That's a good way to put it.  One counterargument is that jQuery (or
>> other authors) could implement the behavior you describe with a
>> combination of requestAnimationFrame, page visibility, and timers.
>Maybe we should start by contacting the jQuery folks then....
>(Sorry for the lag; I was on vacation.)
Received on Thursday, 25 August 2011 10:38:18 UTC

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