Ryan VanderMeulen [:RyanVM] Reporter
	Description • 8 years ago

+++ This bug was initially created as a clone of Bug #1251894 +++

Only happens with the mouse wheel, so I assume it's APZ. Has the same regression range as bug 1251894 as well. The patch there doesn't fix it, unfortunately.

	Markus Stange [:mstange]
	Comment 1 • 8 years ago

It looks like regular checkerboarding to me, but the fact that it didn't occur before bug 1251894 says otherwise.

	Markus Stange [:mstange]
	Comment 2 • 8 years ago

Er, before bug 1231538.

	Ryan VanderMeulen [:RyanVM] Reporter
	Comment 3 • 8 years ago

Scrolling it was jankier before that, though.

	Markus Stange [:mstange]
	Comment 4 • 8 years ago

Oh, now it makes sense! Scrolling that particular part of the page didn't use APZ due to bug 1238571, which bug 1231538 fixed. So what you're seeing now really is just regular checkerboarding. Not much we can do here other than improving displayport sizes / positioning and making painting faster.

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

Ryan, can you repro the problem, then go to about:checkerboard, find the checkerboard report corresponding to it, copy the raw log from the textarea at the bottom, and attach it to this bug? That will give us info about the displayport size and scroll velocity and such which should help us understand it a bit better. Thanks!

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

Shows that the paint took 584.651ms to get through, which seems pretty long. But yes, this is regular checkerboarding and I don't think it qualifies as a release blocker. Reducing the size of the displayport would probably help bring that paint time down, that seems to be main problem. Now that the displayport size tuning experiment (bug 1251052) has been running a while I'll re-analyze the telemetry data from that and try to figure out how much we can afford to trim the displayport by.