On Thu, Aug 29, 2013 at 8:04 AM, Simon Fraser <smfr@me.com> wrote: > The problem is that it defeats one of the main optimizations which drove > our creation of a declarative sticky behavior, which is that we want to be > able to delegate the implementation of the sticky behavior to another > thread, the thread on which scrolling happens (keeping it off the main > thread means that scrolling can remain responsive even when the main thread > is busy doing layout/painting). If we have to do layout when an element > enters or leaves the sticky state, then we’ll have to do that back on the > main thread, which would result in a scrolling stutter. > You could make the "stuck" state apply lazily, so scrolling wouldn't stutter but a shadow (for example) would not appear or disappear immediately. You could also implement it "properly" by sending two versions of the element to the compositor thread: one drawn in the stuck state, another drawn not in the stuck state, and let the compositor pick which one to sue. That would be somewhat horrible to implement though. 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 * *
Received on Wednesday, 28 August 2013 22:47:39 UTC