On 10/13/13 6:23 PM, Robert O'Callahan wrote:
Gecko (and Webkit/Blink) already do stuff like that, insofar as scripted transform changes and changes to certain other properties do not cause reflow. When there are multiple changes, some of which require reflow and some of which don't, you need to wait for the reflow to happen because otherwise you could render an invalid frame.
Hmm. So I guess this means that animation proxies actually have behavior that's different from setting the property directly: it can cause properties of the layer to immediately change irrespective of any pending reflows.
This seems like a useful capability to have. In fact it seems to me that it's somewhat orthogonal to off-main-thread animations. In a deeply multithreaded engine like Servo layout happens in the background, so it may be useful to have an operation like "update this transform now, I don't care whether the contents of the layer are up to date".
The biggest downside is that if the main thread gets busy with script activity, the animation janks.
Sure. But I think that we needn't presuppose that script activity is unpredictable and uncontrollable by the Web app. In the native app world, the mantra is "put everything long-running into a background thread, and use the main thread only for actions that you know will be fast". I don't see any reason why this idea is incompatible with Web apps, and in fact I don't see any other way for performant Web apps to be structured, for reasons such as the fact that events are delivered to the main thread.
One of the high-level goals of Servo is to have nothing happening on the script task besides scripts under the control of the Web app (by running layout and cross-domain tabs and iframes in the background). If we accomplish this, then I think Web authors can "take the main thread back": there should be nothing running on the script thread except JavaScript that the Web developer explicitly wrote. With that and an easy story for Web developers to punt long-running computations onto a background thread, we should have a workable, proven solution for responsive apps.
Patrick _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
