How does this relate to the async animations we are already performing on the compositor thread today? Isn't that sufficient for most animations people want? (transform, opacity).
Andreas On Oct 13, 2013, at 1:43 PM, Patrick Walton <pwal...@mozilla.com> wrote: > This did make me realize something, however: If there are a subset of CSS > properties that can be changed from a worker thread, then those layout > properties can be changed from the main thread as well, without a trip > through layout. In other words: When changing something like transform, if > the node in question is layerized, we could talk directly to the compositor > from the script task. One could imagine at least some subset of events also > working this way, for example scrolling: the compositor could send a scroll > event directly to the script task if it knows about a scrollable frame and > the DOM node it maps to. If layout is asynchronous and the script task is not > blocked on it, then it can respond directly to those events on the main > thread, as native apps do. > > This strikes me as a technically better solution, because it provides some > mechanism for receiving events, as well as all the other main-thread-only > APIs (such as reading from the DOM!) in the thread that's responsible for the > animation. It's also hugely more usable to Web authors, because it doesn't > require use of Web workers and the message passing that comes with it to get > good performance. The downsides are that it requires Web authors to not use > the blocking layout APIs to avoid shooting themselves in the foot, and that > it requires Servo's off-main-thread-layout design, which Chromium seems to > have unfortunately decided against. > > Patrick > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
