Closed Bug 1024595 Opened 7 years ago Closed 7 years ago

Display port setting on first-paint isn't working correctly

Categories

(Core :: Graphics: Layers, defect, P1)

All
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED DUPLICATE of bug 1028002
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: cwiiis, Assigned: botond)

References

Details

(Keywords: perf, regression, Whiteboard: [c=regression p= s= u=2.0])

Attachments

(1 file)

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.
Attached video Video of issue
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).
Blocks: 982141
No longer blocks: 943348
blocking-b2g: 2.0? → 2.0+
Botond, are you the right person to look at this?
Assignee: nobody → botond
(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?
Flags: needinfo?(chrislord.net)
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.
Blocks: input-thread
Keywords: perf
Whiteboard: [c=regression p= s= u=2.0]
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 ?)
QA Contact: pcheng
Priority: -- → P1
Status: NEW → ASSIGNED
Severity: normal → blocker
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
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.
Flags: needinfo?(chrislord.net)
Confirmed fixed in 2.0.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1028002
You need to log in before you can comment on or make changes to this bug.