Jeff Muizelaar [:jrmuizel] Reporter
	Description • 8 years ago

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)

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 1 • 8 years ago

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

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 2 • 8 years ago

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.

	Pulsebot
	Comment 3 • 8 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/ea3161335940

	Carsten Book [:Tomcat]
	Comment 4 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/ea3161335940

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 5 • 8 years ago

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.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 6 • 8 years ago

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

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 7 • 8 years ago

Marking affected for 46 since we have apz enabled there.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 8 • 8 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 9 • 8 years ago
bugherder uplift

https://hg.mozilla.org/releases/mozilla-aurora/rev/e2d8b0cc0b0c

	Petruta Horea [:phorea], Desktop QA
	Comment 10 • 8 years ago

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?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 11 • 8 years ago

(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.

	Petruta Horea [:phorea], Desktop QA
	Comment 12 • 8 years ago

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?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Assignee
	Comment 13 • 8 years ago

(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.