On Sunday, February 15, 2015 at 4:48:06 PM UTC-5, Robert O'Callahan wrote: > Their current idea is to add a new CSS property "scroll-blocks-on" to let a > page opt into sync scrolling: > https://docs.google.com/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit# > In pages that drop below some performance threshold (e.g. 30fps), the > browser can disable scroll-blocks-on. > > A more general version of the latter is to have the browser maintain a > per-document mode switch that's "green" while the document is hitting > performance targets and "red" when it is not, with an event firing for mode > changes. In red mode, features like "scroll-blocks-on" would be disabled. > We could potentially tie in other things here like will-change disabling.
I can't say I'm a fan of this idea. For one thing, I feel like there might be a lot of cases where we rapidly switch between hitting the fps target and not, which will generate lots of spurious mode-changes events. Those events will further slow things down because more scripts will run as a result. It will also result in a very inconsistent user experience if say the parallax effect works half the time but not the other half, just based on whether some other process is hogging the CPU or not. If we do introduce a scroll-blocks-on property, then I think it should be unconditional - that is, the browser should respect it regardless of the perf implications, and it would be up to the author to make sure that perf is good. If we detect the perf is bad then we could just terminate the page entirely, or notify the user that the page is not responding, but I think adding this concept of a "mode" where it's not respected doesn't help anybody. I also agree with Milan that this is exposing more browser implementation detail, which I would like to avoid. kats _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
