You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal seems to be mainly concerned with limiting resource size; have you considered adding a mode/policy to force all scrolling on the compositor thread?
For example: today, a positioned scroller with a clip will prevent compositing so all scrolls will be only as responsive and smooth as the main thread allows. We could have a flag/FeaturePolicy that forces compositing in all cases to ensure responsiveness at the cost of correctness.
We had this experience with a local team that was struggling with performance issues on a low-end device. Figuring out why scrolling is slow required knowing the browser internals and it was very easy for regressions to slip in. It'd be much easier for developers if they could guarantee fast scrolling and then have to notice that "hey, background-attachment: fixed isn't working".
The text was updated successfully, but these errors were encountered:
This proposal seems to be mainly concerned with limiting resource size; have you considered adding a mode/policy to force all scrolling on the compositor thread?
For example: today, a positioned scroller with a clip will prevent compositing so all scrolls will be only as responsive and smooth as the main thread allows. We could have a flag/FeaturePolicy that forces compositing in all cases to ensure responsiveness at the cost of correctness.
We had this experience with a local team that was struggling with performance issues on a low-end device. Figuring out why scrolling is slow required knowing the browser internals and it was very easy for regressions to slip in. It'd be much easier for developers if they could guarantee fast scrolling and then have to notice that "hey, background-attachment: fixed isn't working".
The text was updated successfully, but these errors were encountered: