It would appear that something has broken the displayport setting code that takes care of making sure scrollable sub-frames have display-ports set on their first paint. The consequence of this is that there's a noticeable period after trying to scroll where scrolling doesn't happen for some (most?) Gaia apps, especially on start-up. This is especially evident in Settings. I'm having a quick look to see if it's an obvious problem. This is a regression that has serious user-visible performance impact, so I've nominated it as a blocker.

I wonder if this is a consequence of the same Gaia change that caused bug 1022746? If the sub-frame doesn't exist on the first-paint, will it get a display-port if it comes into existence afterwards?

(In reply to Chris Lord [:cwiiis] from comment #0) > It would appear that something has broken the displayport setting code that > takes care of making sure scrollable sub-frames have display-ports set on > their first paint. Small clarification: we make the the "primary async-scrollable subframe" has a displayport set on its first paint, not all subframes. For reference, bug 982141 is what introduced this. > This is especially evident in Settings. As mentioned on IRC, I do not see this in Settings, nor have I noticed it elsewhere. I was testing with a Nexus 4 running this Monday's nightly. I'd definitely like to look into this if I can reproduce it! (In reply to Chris Lord [:cwiiis] from comment #2) > If the sub-frame doesn't exist on the first-paint, will it get a > display-port if it comes into existence afterwards? It should, since the code that picks up the primary async-scrollable subframe and makes sure it has a display port runs during display list building.

(In reply to Botond Ballo [:botond] from comment #3) > Small clarification: we make the the "primary async-scrollable subframe" "make _sure_ the"

The feature that appears to have regressed is the setting of a displayport for a subframe, so a dependency on bug 982141 is more appropriate (bug 943348 concerned the root frame).

Botond, are you the right person to look at this?

(In reply to Milan Sreckovic [:milan] from comment #6) > Botond, are you the right person to look at this? I would be if I weren't away for three weeks :) I'll do my best to assist though. As I mentioned above, I cannot reproduce this on my Nexus 4. Chris, who can reproduce this on his Flame, said he will post layer dumps before and after scrolling - that might give us a clue as to what is going on.

Hey Chris, with Botond away for a while, and us not wanting to fix this 2.0 blocker that far away, after you post the layer dumps, can you see if you can figure out what's going on?

I notice this problem with the vertical home screen. There is a noticeable delay on the first scroll once we move the APZ logic onto the input thread.

I think it'll be a lot easier to go from a regression window rather than a layer dump. Let's get a window on this. STR, on a Flame device: 1- Open Settings 2- *As soon as* the list appears, try to scroll it For step 2, do not use multiple gestures, place your finger on the screen as soon as the list appears and try to scroll - do not lift your finger. Expected: List should scroll. Actual: List does not scroll (see attached video). Note, I don't think this is a Gaia-induced issue, as I see the results of displayports not being set in the browser: Open up Twitter and scroll down with a quick fling, for example, note that you will immediately checkerboard - there is no pre-rendered content in the displayport. These can serve as alternative STR if necessary, but the steps above are easier and more obvious.

Well, that's lucky, this has been fixed in latest central! So let's get a regression range and find out what fixed it (I suspect a backout, possibly bug 1028216 ?)

b2g-inbound REVERSED regression window: Last Broken Environmental Variables: Device: Flame Build ID: 20140624023251 Gaia: 2cba65f24e53b56a359137c6145e23c0790eb8a6 Gecko: eff939209f44 Version: 33.0a1 (Master) Firmware Version: v122 First Working Environmental Variables: Device: Flame BuildID: 20140624024751 Gaia: 5f2c61ae3bbdad0c46c2ef5c808182a099e429c9 Gecko: 97ce8b3b8ce2 Version: 33.0a1 (Master) Firmware Version: v122 Last Broken Gaia and First Working Gecko - issue does repro Gaia: 2cba65f24e53b56a359137c6145e23c0790eb8a6 Gecko: 97ce8b3b8ce2 Last Broken Gecko and First Working Gaia - issue does NOT repro, which means the fix came from Gaia Gaia: 5f2c61ae3bbdad0c46c2ef5c808182a099e429c9 Gecko: eff939209f44 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/2cba65f24e53b56a359137c6145e23c0790eb8a6...5f2c61ae3bbdad0c46c2ef5c808182a099e429c9

I'm flummoxed as to why that change caused this problem, but glad that it's fixed - this commit has been merged to 2.0, I'll verify later if it's fixed there and dupe this bug accordingly.

Confirmed fixed in 2.0.