Loading this page https://android.googlesource.com/platform/external/deqp/+/master/modules/gles3/functional/es3fShaderOperatorTests.cpp we end up with a very large display port. Safari's is much less and seems better. Given that windows are typically wider than they are tall, we likely need less margin on the sides of the display port than the top (especially on desktop)

Once the telemetry is in we can run an experiment to reduce the width of the displayport and see how it impacts things.

I made the desktop displayport width prefs match mobile for simplicity. Really we want to push these as low as we can go without increasing checkerboarding, so it will take further patches and tuning. I think this is probably fine to start.

From the telemetry data the number of checkerboard events has dropped since this landed, although there hasn't been enough data collection yet to clearly see the before/after. Still I think this is worth uplifting to 46.

Comment on attachment 8723222 [details] [diff] [review] Patch Approval Request Comment [Feature/regressing bug #]: APZ [User impact if declined]: on wide pages, the browser will paint a lot of extra content to the left/right of what the user is seeing, which is mostly wasted because users don't scroll horizontally that much. This results in wasted CPU/memory/power and slows things down overall. [Describe test coverage new/current, TreeHerder]: pref change not really tested specifically. I've been monitoring telemetry from Nightly to ensure that there is no negative fallout [Risks and why]: low risk, just pref changes. [String/UUID change made/needed]: none

Marking affected for 46 since we have apz enabled there.

Comment on attachment 8723222 [details] [diff] [review] Patch Pref changes for display width with apz. OK to uplift to aurora. It would be good to verify this fix on 46 though.

I see no difference while loading page [1] in a Nightly build before the fix and the latest Nightly 2016-03-28. I was expecting the difference to be visible and the margins to be narrowed. I checked both under Windows 7 64-bit and Mac OS X 10.9.5. [1] https://android.googlesource.com/platform/external/deqp/+/master/modules/gles3/functional/es3fShaderOperatorTests.cpp How could this be verified fixed?

(In reply to Petruta Rasa [QA] [:petruta] from comment #10) > How could this be verified fixed? It's going to be hard to observe visually because the margins being narrowed just means in some cases you'll encounter checkerboarding a little more frequently when scrolling horizontally. However if you turn on the apz.minimap.enabled pref from about:config, you should see that the green box is a little narrower than it used to be. That should be sufficient to verify the fix.

Thank you! Verified as fixed using latest Aurora 47.0a2 and latest Nightly 48.0a1 under Win 7 64-bit and Mac OS X 10.9.5. I noticed that the width of the green box is narrowed when scrolling horizontally using the trackpad. Is this an issue that should be tracked separately?

(In reply to Petruta Rasa [QA] [:petruta] from comment #12) > I noticed that the width of the green box is narrowed when scrolling > horizontally using the trackpad. Is this an issue that should be tracked > separately? No, this is expected behaviour at the moment. When scrolling above a certain velocity we shrink the width of the displayport further.