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
