RE: scroll-delay: enabling control over the scrolling synchronization policy

± I agree we need to follow the extensible web manifesto here and built more
± expressive primitives for scrolling.  Those primitives should explain the
± underlying browser platform.  Given all major browsers now have multi-
± threaded scrolling architectures, it follows that the primitives should take
± advantage of that. 
±
± The current proposal actually backs away from explaining
± the underlying platform and instead tries to shim the platform into sort-
± of/kind-of/but-not-really working like iOS/Android app scrolling. While yes
± we can improve main-thread-synchronous performance, it will never eclipse
± what can be achieved with multi-threaded scrolling.  My 2 year old phone has
± 4 cores--the web should be empowered to take advantage of that and
± maybe even use that to eclipse native performance.  Non-blocking, multi-
± threaded scrolling is what enables the web platform to escape the additional
± challenges Ben mentioned about runtime variances.
± 
± For these reasons, it seems much more rational to continue investigating
± isolated script contexts that can control scrolling and manipulation while
± more accurately explaining how the underlying platform actually works.
± You've mentioned a UIWorker concept that sounds intriguing along these
± lines.  It avoids the pits of failure for perf, allows bespoke UI experiences,
± and helps developers overcome the challenges of building for runtimes and
± devices of varying performance characteristics. I think something like that is a
± better approach than scroll-delay.

FWIW, I agree with you that isolated script contexts is something the web platform desperately need to dig more, and it certainly does seem interesting in the context scrolling. Most scroll effects could probably be achieved by exposing to a worker thread a bunch of web animation / css animation timelines (writable values from 0.0 to 1.0 indicating the animation progress) that it could seek backwards/forwards depending on the touch interaction, and which would affect the current animation frame being rendered on the main thread. 

That being said, can we safely ignore the argument that says that "Touch Events are here to stay" (at least in a foreseeable future) and that making accommodations to it may improve the performance users see today on their devices?

While I hear your desire not to push developers towards synchronized scrolling, I think a compromise would already be possible by specifying uncontroversial values like "scroll-delay: auto | none" (part of the document whose scroll is not affected by the user-registered gestures) and "touch-action: auto | none" (part of the document where the user-registered gestures are not affected by any kind of built-in gesture) and see where we can go from there.

Received on Friday, 10 October 2014 20:37:52 UTC