Closed Bug 629475 Opened 9 years ago Closed 9 years ago
Regression: displayport takes longer to refresh
I am testing a patch on bug 629146, and since yesterday platform has regressed with refreshing content. It was working great here: http://hg.mozilla.org/mozilla-central/rev/5a0f46c26d12 But not here: http://hg.mozilla.org/mozilla-central/rev/09bfc85b151c I'm triaging to find the bad revision.
This bug report is short on information. Are you observing the slowdown while panning? Or when, say, two-finger swiping to top-bottom to force a full-window repaint?
The slowdown is while panning, and it's an obvious regression on my phone when panning around on most sites. For instance, with the moving-target patch and yesterday's build, content would refresh less than a second after beginning the pan. Today, the pan will pretty much finish before it shows any content. The only thing that changed was platform.
OK. The regression range includes drawing the checkerboard. It might be that the browser process is chewing more CPU now and choking out the content process. Could test by commenting early-returning from BuildBackgroundPatternFor() in RenderFrameParent.
OK, confirmed that it's the checkerboard.
As we discussed on IRC, a simple tuning knob here is to make the background image larger. Ideally cairo would be smart about this, but spitting in one hand etc. There's a great perf-measurement class in js/src/perf/jsperf.h that ought to work in >= 2.2, which would allow tuning the size quantitatively. Start it counting before the background fill, stop after, record cycle counts + cache missed, lather rinse repeat. I'd be fine with disabling checkerboard again in the meantime.
(And of course, sadly, GL would make this moot.)
I can confirm the regression from b3 to b4 on android. I would also like to point out that from a perception point of view, the checkerboard background "feels slower" than a white background
If we're set on keeping the checkerboard, then comment 5 is probably easiest way to cut down on CPU. It can be measured quantitatively too.
Did I do this right? :) I wanted to bump the image from 16px to 64px and see how the paints worked. On planet.mozilla.org it looks like it is painted faster and I see less small block paints.
Assignee: nobody → mark.finkle
Attachment #511843 - Flags: review?(jones.chris.g)
Is there / will be any option in about:config to turn off the checkerboard completely?
Bug 627828 is about making the background (checkerboard) image customizable.
Comment on attachment 511843 [details] [diff] [review] patch - 64px checkerboard This patch could be made smaller with more macro-ization, but it's a hack on a hack so I'm inclined not to care. It's not very hard to measure the perf difference quantitatively, even without jsperf, e.g. with a TimeStamp before and after drawing the checkerboard.
Attachment #511843 - Flags: review?(jones.chris.g) → review+
I was able to add some timing code here: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/basic/BasicLayers.cpp#730 Normal painting was fast. But painting while panning seemed to be slower. This is in both cases - with and without patch. Without the patch, painting while panning was ~25-30 ms With patch, painting while panning was ~12-18 ms So we could be averaging ~44% better with the patch. Good enough to land.
pushed: http://hg.mozilla.org/mozilla-central/rev/525db94bf558 let's file new bugs on specific issues
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Verified on build: Mozilla /5.0 (Android;Linux armv7l;rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre Fennec /4.1a1pre Device: Samsung Captivate (Android 2.2 update 1)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.