Closed Bug 1247280 Opened 4 years ago Closed 4 years ago
Consider changing the APZ content response timeout
58 bytes, text/x-review-board-request
Right now APZ's content response timeout is set to 300ms. Rick says that "In Chrome we currently use either 150ms (desktop viewport) or 1000ms (mobile viewport) timeout. Safari had been confused but they are moving (or have moved) to a consistent 1000ms timeout." We should probably add some telemetry to see how long the content response takes in practice for us and consider bumping our content response timeout accordingly.
Whiteboard: gfx-noted,feature → gfx-noted
Depends on: 1261373
Summary: Considering changing the APZ content response timeout → Consider changing the APZ content response timeout
Desktop: http://mzl.la/1XShUB1 Mobile: http://mzl.la/1MTbTn8 On Desktop the current timeout of 300ms gets us around 98.5% of the response. At 150ms we'd get around 97%. On Mobile, the current timeout of 300ms gets us around 97% of the responses, and bumping it to 1000ms would get us approximately 99.6%. Not sure what we should aim for. Maybe 99%? That would be around 400ms on desktop and 600ms on mobile. That's going off the last 6 days of data though, we should probably let a bit more data accumulate before making the final call.
Looks like the numbers are about the same on the the full 49 nightly data - for 99% we want 400ms on desktop and 600ms on mobile.
Review commit: https://reviewboard.mozilla.org/r/59312/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59312/
Attachment #8762856 - Flags: review?(botond)
Comment on attachment 8762856 [details] Bug 1247280 - Bump the APZ content response timeout so that we get 99% accuracy. https://reviewboard.mozilla.org/r/59312/#review56352
Attachment #8762856 - Flags: review?(botond) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/5ef082038aee Bump the APZ content response timeout so that we get 99% accuracy. r=botond
Kats, is there any targeted manual testing that we should perform around this?
There's probably some value in testing scrolling on pages with heavy CPU load or when the page has wheel/touch listeners that take a long time to run. In the general case this patch shouldn't have much of an impact, but if the main thread is slow to respond then we might take a little longer to start scrolling, to give content more time to respond to the listeners.
Probably also worth retesting bug 1262672 to see if it's still reproducible.
We've tested some heavy websites using latest Nightly across platforms and didn't saw any issues. We're planning to do another set of tests before the merge. Will update the bug then.
This can ride the trains, I don't think it's urgent to uplift at the moment.
Nothing new found on Nightly 50, marking as verified (forgot to update the flag sooner).
3 years ago
Depends on: 1302493
You need to log in before you can comment on or make changes to this bug.