1243081 - Scrolling code on github.com is janky

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/src/hip_hcc.cpp

I suspect we are doing something stupid here, but I haven't investigated what.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

From a profile it looks like we're doing massive amount of texture uploading.
The inner content gets an APZ and that's probably not helping.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Using the patch on bug 1231396 it looks like we are painting more than 2x pixels when scrolling the root scrollframe on this page when the subframe is layerized vs. when it is not layerized. There are also spikes of up to 12x. It's quite possibly my code is wrong but still something seems amiss.

Not layerized:
Ending transaction with 0 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 370080 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 3686400 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 368640 painted pixels
Ending transaction with 0 painted pixels

Layerized:
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 4560997 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 0 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 790986 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 4560997 painted pixels
Ending transaction with 787712 painted pixels
Ending transaction with 787712 painted pixels

Comment 3

[Kartikaya Gupta (email:[e-mail])]

So we're painting two screenfuls on each paint because there's the outer layer and the inner layer. The 368640 comes from 256x1440 (virtual tile height times my screen width) and the 787712 is 368640 + (256 x 1637) (outer layer paint plus virtual tile height times subframe displayport width). So that's all pretty much expected. I don't know where the outlier numbers are coming from but seems like occasionally we paint a bunch more, with or without the subframe layerized (note that the non-layerized output above has one instance of a 10x value, 3686400).

I don't think there's much we can do here in terms of layerization or displayport sizes if we want to retain the same displayport margins. Perhaps an approach like that of bug 1261166 might help.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

I logged all transaction times using the code at [1] with and without bug 1261166, scrolling around on this page. The difference was huge!

Without bug 1261166:
  Samples: 441
  Average:       0.02
  Stddev:       0.18
  Max: 3
  Min: 0
  Sum: 9

With bug 1261166:
  Samples: 404
  Average:       6.53
  Stddev:       9.47
  Max: 50
  Min: 0
  Sum: 2640

Some of the samples were from about:home and whatever, but there's still a very significant difference. Considering this "janky scrolling on pages with big iframes" issue has only been reported on OS X (and even then appears to more noticeable on retina screens) I think we should pursue this OS X-specific fix for it.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/LayerTransactionParent.cpp?rev=cb2023f50288#650