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

Re: Open Source Cross-Browser setImmediate in JavaScript

From: Paul Bakaus <pbakaus@zynga.com>
Date: Thu, 7 Jul 2011 08:46:57 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <CA3BA0DD.AFD4%pbakaus@zynga.com>
That's interesting and sad at the same time..

It's a pain that transitions and animations currently can't be trivially
started, stopped, restarted and overridden. There still needs to be a lot
of work put into CSS Animations and transitions before we can actually
expect normal developers to sanely work with them.

Am 07.07.11 17:37 schrieb "Boris Zbarsky" unter <bzbarsky@MIT.EDU>:

>On 7/7/11 10:11 AM, Paul Bakaus wrote:
>> That's the thing  I'm wondering out the same thing, so I'd love to know
>> where the difference really is. setTimeout often feels to slow  for
>> instance, to start or restart CSS animations or transitions, you have to
>> wait for a relayout, which is where I'm using setTimeout.
>Of course that doesn't actually work correctly, per
>unless you use a pretty long timeout value...
>> My guess is that setImmediate wouldn't wait for layout batches to be
>> finished, but only JS
>If it's running on the same event loop as layout (which as far as I can
>tell it is), then it would have to wait for layout to not be running.
>> so you might call it while code is executing and
>> would know it's executed right after the rest of your current stack has
>> been worked off, but before layout changes.
>I don't think it offers any such guarantees.  Certainly not as currently
>Note that layout can change synchronously if something flushes it, by
>the way, so there's no async setup that can guarantee running before
>layout changes.
Received on Thursday, 7 July 2011 15:47:37 UTC

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