This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26839 - Integrate "Timing control for script-based animations" spec into HTML
Summary: Integrate "Timing control for script-based animations" spec into HTML
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
: 26636 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-17 22:52 UTC by Ian 'Hixie' Hickson
Modified: 2014-11-19 21:57 UTC (History)
8 users (show)

See Also:

Attachments

Comment 1 Ian 'Hixie' Hickson 2014-09-17 23:17:45 UTC 
See also http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0048.html
Comment 2 Ian 'Hixie' Hickson 2014-09-19 23:43:04 UTC 
*** Bug 26636 has been marked as a duplicate of this bug. ***
Comment 3 Ian 'Hixie' Hickson 2014-09-19 23:43:16 UTC 
See also http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0091.html
Comment 4 Ian 'Hixie' Hickson 2014-09-26 22:53:57 UTC 
Looks like the model should be:

 1. scroll events and other such events that we want synchronised with rendering
 2. requestAnimationFrame callbacks
 3. microtasks triggered by requestAnimationFrame
      -- beyond this point no script executes until we've painted --
 3. resolve CSS animations, transitions, etc
 4. compute style
 5. compute layout
 6. paint
Comment 5 Ian 'Hixie' Hickson 2014-10-10 18:25:16 UTC 
What do people think? Is this controversial?
Comment 6 Travis Leithead [MSFT] 2014-10-10 20:13:43 UTC 
I have a little trouble with the "update the rendering" concept in general--it makes a lot of assumptions about a single-threaded rendering environment. In IE's case, we use a multi-threaded rendering model, and so "update the rendering" is not going to be so straightforward.

Regardless of this, if the editors of the Timing control.. spec want to integrate, then I suppose I don't object; though in general, I'm a proponent of smaller modular specs of which this plan runs counter to that goal.
Comment 7 Anne 2014-10-10 22:19:13 UTC 
I think this makes sense. I'd be interested in hearing how we can allow for parallelization in rendering better. Travis, I assume you still deal with synchronizing scroll events and requestAnimationFrame callbacks and such somehow?

I think in the end what this is doing is synchronizing when certain rendering bits happen that have hooks in scripts. Rendering itself is after that (3-6 in Ian's list) and those things could happen in parallel.
Comment 8 Ian 'Hixie' Hickson 2014-10-11 01:09:06 UTC 
Travis: I'm interesting in hearing more about the multithreaded rendering model. What kinds of things do you do in separate threads? Are any of the things in comment 4 done in separate threads?
Comment 9 contributor 2014-11-19 21:56:53 UTC 
Checked in as WHATWG revision r8849.
Check-in comment: Flesh out how rendering happens in the event loop. This also defines requestAnimationFrame() and obsoletes the 'Timing control for script-based animations' spec (by request of that spec's editors)
https://html5.org/tools/web-apps-tracker?from=8848&to=8849
Comment 10 Ian 'Hixie' Hickson 2014-11-19 21:57:09 UTC 
Travis, let me know if the resulting spec text is problematic for IE. Thanks.