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

Scrolling hard on a MBP on http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151221/thread.html

If you watch the (3,12,10) controller in http://people.mozilla.org/~kgupta/rendertrace.html you'll see there's a moment where the requested viewport jumps to the bottom of the page after which things are not so good. The viewport eventually gets back to where it's supposed to be but we've already checkerboarded hard.

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

Here's a standalone version of the rendertrace recording with the data hard-coded in. It wasn't clear to me from playing through it a couple of times which frame has the crazy jump you're describing but I haven't had time to go through it frame-by-frame.

	Jeff Muizelaar [:jrmuizel] Reporter
	Comment 2 • 9 years ago

The jump happens in frame 144

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

Frame 144 shows the painted displayport at the bottom of the page. I believe this corresponds to the paint request in frame 123, where we request a displayport at the bottom of the page. That does look like a bug, though - the viewport isn't moving very much so there's no reason the velocity bias should throw it that far. The rendertrace doesn't have actual numbers for the velocity and stuff but I'll make sure to log that info in the souped-up checkerboard recording in bug 1226826.

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

Markus filed a more general bug to cover this behaviour, so I'm forward-duping this to that one.