On Sun, Oct 13, 2013 at 4:03 PM, Patrick Walton <pwal...@mozilla.com> wrote:
> * I foresee tricky synchronization problems to keep the DOM objects that > proxied objects in workers refer to in sync with what's happening on the > main thread. In Gecko (and Servo) layers can appear or vanish in response > to various events that are main-thread-specific. > That's not a problem; the creation of an animation proxy would force layerization of an element. * This is very short-term thinking, in that it handles only one case > (animations), and lacks the capability to respond to events. For example, > for touch-sensitive scrolling you want the ability to stop the scrolling > immediately when a touch-up event comes in. But events are sent to the main > thread, not the worker thread. So in the case of main thread contention > there will be lag as the event gets routed to the worker thread and then > the animation proxy stops. This could be fixed by making an "event proxy" > or something, but this is a slippery slope toward an unmaintainable, > unwieldy API. > Yes, I don't think this idea is suitable for interactive use-cases. There was some discussion of this proposal on www-style. There, it was made clear that this proposal can give better results than main-thread-driven animations but worse results than compositor-thread-driven animations, because we wouldn't want to risk blocking the compositor on the updates performed by a worker. So for example our builtin support for position:sticky is better than you'd get if you emulated position:sticky in a worker. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
