[checkerboarding] Lots of {{background-color}} when panning in Gaia apps

RESOLVED FIXED

Status

()

defect
P1
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: vingtetun, Assigned: milan)

Tracking

({meta, perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.3T affected, b2g-v1.4 fixed, b2g-v2.0 unaffected)

Details

(Whiteboard: [c=handeye p= s= u=1.4] [apz_testrun])

Attachments

(3 attachments, 1 obsolete attachment)

With APZ turned on trying to scroll any scrollable list in Gaia apps results into a lot of white showing when panning.

This can be viewed into the call log, the sms app or the contacts apps.

Steps to reproduce:
 - If you have a Gaia without any data (calls, messages, contacts, ..), go into the gaia directory and do |make reference-workload-medium|
 - launch Gaia with APZ turned on
 - Open the dialer app, and switch to the call log (bottom left tab)
 - Wait for it to be loaded and starting panning to show the bottom of the list

Expected result:
 - Smooth scrolling without any white ares

Actual results:
 - occasionaly a white area is visible before it quickly refresh to show the scrolled content.

Note: It seems easier to trigger by scrolling into one direction and then suddenly scroll the invert direction.
OS: Linux → All
Hardware: x86_64 → All
Summary: Lots of white when panning in Gaia apps → Lots of {{background-color}} when panning in Gaia apps
I made a rendertrace recording of scrolling around in the call history. Initial impressions are that painting seems to take too long, which is why we often end up in regions that haven't been painted yet. Tiling would probably help a lot here but we should be able to do better even without it. I'll investigate a bit more.
The dupe of this bug seems pretty bad - we can turn the gallery app completely black during scrolling.
blocking-b2g: --- → 1.3?
Whiteboard: [apz_testrun]
The symptoms are similar, yeah. However this bug covers excessive "temporary" checkerboarding behavior. That bug included other root causes that would sometimes leave the content entirely blank and unrecoverable.
BenWa, thoughts?
Flags: needinfo?(bgirard)
I'll take a look next week. Meanwhile if someone can grab a performance profile of the gallery's main thread + the compositor thread, upload it and post the link here that'd be great.
Trying to figure out whether this is a blocker or not, the consensus is that if you can get this behavior without lifting the finger from the screen, then it's definitely 1.3+.  Vivien, can you get it to happen without the "flick"?
Flags: needinfo?(bgirard) → needinfo?(21)
Milan, I have gotten the settings to not move even though I scrolled down and then it will white out to the background.  This is a pretty bad visually.
ie, I vote this to be a 1.3+
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9)
> Milan, I have gotten the settings to not move even though I scrolled down
> and then it will white out to the background.  This is a pretty bad visually.

Can you post a video?
Given that apzc is landing on 1.3, we want to take this for 1.3+ blocking.
blocking-b2g: 1.3? → 1.3+
Note comment 8 - because this is asynchronous behaviour, we will always be in a position where we get the checkerboarding, we just want to define what is acceptable and what isn't.  There is enough in this bug that is a blocker, but the "smooth scrolling without any white areas" is not a reasonable goal.  I'll leave it as 1.3+ while we sort out what's what.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from
> comment #9)
> > Milan, I have gotten the settings to not move even though I scrolled down
> > and then it will white out to the background.  This is a pretty bad visually.
> 
> Can you post a video?

Naoki, is it like the video in bug 958073?
Flags: needinfo?(21) → needinfo?(nhirata.bugzilla)
By the way, bug 958073 shows up with and without APZC, so I just want to make sure we're not mixing different issues into the same bug.  Naoki, when you ran into the "doesn't move at all", was it possible to do that with APZC off?
Duplicate of this bug: 957925
Note - during today's 1.4 testing, this is very easy to reproduce on marketplace by scrolling through search results.
Assignee: nobody → bgirard
No longer blocks: 942267
hi milan: I believe it's an APZ issue.  The settings scrolls fine when the APZ is turned off.  When APZ is turned on, it might not move and later on white out.

This is with 1.4 as well as 1.3
Gaia      22bc6be5b76cdc6d4e9667ff070979041a20ce2f
Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/2c8f8683bd0d
BuildID   20140109004002
Version   28.0a2
ro.build.version.incremental=eng.archermind.20131114.105818
ro.build.date=Thu Nov 14 10:58:33 CST 2013
Flags: needinfo?(nhirata.bugzilla)
Hi there. I don't know if the bug I am seeing is related but somehow the most simple html page consisting of only 33 lines of text is rendered black as soon as I scroll. My background-color is not black though.

Here is the page: http://ffos.ddenis.info/renderbug1/

Video showing the issue: http://youtu.be/XmUOZh9rJBg
Disabling APZ makes the bug go away.
Duplicate of this bug: 951259
Blocks: 942267
No longer blocks: 942267
See bug 951259 comment 10 for a summary of the different issues. This bug tracks checkerboarding problems in gaia.

(In reply to Denis Dzyubenko [:ddenis] from comment #19)
> Hi there. I don't know if the bug I am seeing is related but somehow the
> most simple html page consisting of only 33 lines of text is rendered black
> as soon as I scroll. My background-color is not black though.
> 
> Here is the page: http://ffos.ddenis.info/renderbug1/
> 
> Video showing the issue: http://youtu.be/XmUOZh9rJBg

This looks more like we're running out of memory, and doesn't appear related to this bug (although the symptoms sound similar). Could you please file a new bug for this? It might be the same issue as bug 957925 but it might be something else so I don't want to mix them up just yet.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9)
> Milan, I have gotten the settings to not move even though I scrolled down
> and then it will white out to the background.  This is a pretty bad visually.

I think the "not moving" part is something else. I will file a new bug for that. The "white out to the background" sounds like checkerboarding but I would need a video to make sure.
Summary: Lots of {{background-color}} when panning in Gaia apps → [checkerboarding] Lots of {{background-color}} when panning in Gaia apps
I filed bug 958549 for the settings app issue.

Comment 24

5 years ago
Attaching a video of the original issue reported by  Vivien Nicolas with scrolling on the Contacts App (observed with AZPC enabled only).

STR: Same as original steps (using |make reference-workload-medium|).

Comment 25

5 years ago
Posted video 20140110_095550.mp4
So considering that we only checkerboard under "reasonable" scenarios (i.e. flinging as fast as humanly possible, or reversing directions suddenly) and considering comment 13, I think we should move this to not block gaia-apzc any more, but mark it as follow-up work (i.e. blocking bug 949585). Any objections?
blocking-b2g: 1.3+ → 1.3?
It's a bad UX for the end user; the panning various locations such as the marketplace and settings has a delay in the update of the screen when we encounter this bug and it then whites out the screen.
blocking-b2g: 1.3? → 1.3+
I also don't think we should really dig into checkerboarding problems until we've fixed bug 957668, as it will change a fair amount of this code. I'm unassigning this from BenWa because of this, and also because he's busy with other bugs at the moment.
Assignee: bgirard → nobody
Depends on: 957668

Comment 29

5 years ago
PM triaged this bug and believes that it should be a blocker.

Updated

5 years ago
Blocks: 942267
Keywords: perf
Whiteboard: [apz_testrun] → [apz_testrun][c=handeye p=3 s= u=1.3]
-> Milan, pending plan for this
Assignee: nobody → milan

Comment 31

5 years ago
This is a CS blocker. What other CS blockers in BenWa busy with?

Comment 32

5 years ago
Seems like the fix for this is involved and adds considerable risk to 1.3. We can consider pushing this to 1.4. Technically, this is a regression from 1.2 and is a must have feature for 1.4.

Also, for 1.4, can we define the plan for Tiled Rendering (https://bugzilla.mozilla.org/show_bug.cgi?id=887819)
Moving to 1.3? per comment 32 to confirm agreement to move this to a 1.4 blocker.
blocking-b2g: 1.3+ → 1.3?
This is an untested patch that I think may disallow checkerboarding. I may not get the chance to sort this out today, so leaving this here in case anyone wants to check it out. Otherwise will sort it out tomorrow (assuming it doesn't end up taking some silly amount of time).
Worth noting that using progressive rendering, unless the coherency check code is working correctly (it likely isn't), even if this patch does what I intend it to, you may still see checkerboarding.
Unfortunately this patch doesn't work :sadface: I'll fix it tomorrow morning.
The value returned by GetCurrentAsyncTransform itself needs to change.
Also, we should file separate bugs for these different approaches to parachute-knitting.
I grabbed a video + rendertrace of what I see when I try to reproduce this. Yes there is checkerboarding, but it's a very quick flash. It could be longer on some devices and depending on paint times/what else gecko is doing there but this video is representative of what I was able to reproduce after ~15 attempts. The rendertrace that I'll attach next corresponds to this video and shows the model of what's happening in more detail.
In the above trace, whenever the red rectangle (user-visible area) goes outside the green rectangle (painted content) is when there is checkerboarding. The yellow is what we have requested to be painted but has not yet been painted. The checkerboarding in question occurs at frames 131-152.
So drawing aborting would help here to plaster over the problems but there's a lot we can do first.

Here's the first profile I collected:
http://people.mozilla.org/~bgirard/cleopatra/#report=a3ab371e7a8663d3f94e61ed172b2b213684fa17

Several things look wrong here but I want to collect more data before we come to conclusions.
Profile with stacks (less accurate but used to pin-point the cause from the profile in comment 42).
Depends on: 967272
Depends on: 967274
Depends on: 967277
Depends on: 967292
QA Wanted to check the following:

Can we have somebody take a look at the other applications, not
just contacts, and tell us if the problems similar to 942750 show up
elsewhere?  We want to see if there is a Gaia level solution. In
parallel, Nical was pointing me to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=942460, and perhaps that
may help us with the bug above; it would be good if we can test that
patch and see if it gives us the benefit we're looking for.
Keywords: qawanted

Updated

5 years ago
Blocks: 960372
No longer blocks: 942267
jsmith: I've done some of the initial legwork for the Email app in bug 965019. We also have checkerboarding in the email app.
(In reply to Jason Smith [:jsmith] from comment #45)
> QA Wanted to check the following:
> 
> Can we have somebody take a look at the other applications, not
> just contacts, and tell us if the problems similar to 942750 show up
> elsewhere?  We want to see if there is a Gaia level solution. In
> parallel, Nical was pointing me to bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=942460, and perhaps that
> may help us with the bug above; it would be good if we can test that
> patch and see if it gives us the benefit we're looking for.

I have seen checkerboarding in the call log, sms, gallery and music mostly. Sometimes in contacts, settings and the email app.
Keywords: qawanted
Chris, given comment 32:
> Seems like the fix for this is involved and adds considerable risk to 1.3.
> We can consider pushing this to 1.4. Technically, this is a regression from
> 1.2 and is a must have feature for 1.4.
> 
> Also, for 1.4, can we define the plan for Tiled Rendering
> (https://bugzilla.mozilla.org/show_bug.cgi?id=887819)

What are your thoughts on punting this to 1.4?
Flags: needinfo?(clee)
Depends on: 967449
Depends on: 967471
Depends on: 967502
Comment on attachment 8369516 [details] [diff] [review]
WIP: Disallow checkerboarding when using APZC

This has been obsoleted by the patches on bug 967502.
Attachment #8369516 - Attachment is obsolete: true
making it 1.3+
blocking-b2g: 1.3? → 1.3+
No longer depends on: 967442
Depends on: 967884

Updated

5 years ago
Priority: -- → P1
Whiteboard: [apz_testrun][c=handeye p=3 s= u=1.3] → [c=handeye p= s= u=1.3] [apz_testrun]
Can we get ETA to fix this bug? Thank you.
There is no ETA at this moment; there is no single "fix" for this bug, there are multiple approaches and mitigations as seen in the dependent bugs.  Please contact Milan and myself for more details.
Depends on: 968112
Whiteboard: [c=handeye p= s= u=1.3] [apz_testrun] → [c=handeye p= s= u=1.3] [apz_testrun][ETA:2/21]
Depends on: 968505
Going to clear the blocking flag here as this has inevitably turned into a meta bug.
blocking-b2g: 1.3+ → ---
Keywords: meta
One of the strategies we tried to improve checkerboarding perf was to expose different displayport heuristics and options in the gaia prefs and have QA evaluate them to see which worked best. Their results are on the etherpad at [1] but since I don't trust etherpad I'm copying out the relevant summary of results here for posterity. There are two groups of options; the options within a group are ranked in order of user experience (1 is the best).

First group:
_1_ APZ off: smooth no noticeable stutters or checkerboarding even in med/heavy loads
_2_ APZ on, checkboarding off: contained stutters
_3_ Default Options: has white checkerboarding, stutters, and feels jittery especially in heavy loads

Second group: (results were most noticeable in MMS thread with lots of pictures, tie for 1st)
_1_ build with APZC on and display heuristic select menu set to Default (white checkboarding, stutters, jittery)
_1_  build with APZC on and  display heuristic select menu set to Taller  displayport (white  checkboarding, more so with pictures, little bit of  stuttering)
_3_ build with APZC on and display heuristic select menu set to Faster paints (white checkerboarding, little bit of stuttering)
_4_  build with APZC on and display heuristic select menu set to Assume  perfect paints (some white checkboarding more when pictures are  involved, litlle bit of stuttering)
_5_  build with APZC on and  display heuristic select menu set to Center  displayport (lots of white  checkboarding, stuttering when pictures are  involved MMS)

[1] https://etherpad.mozilla.org/APZ-v1-3
Duplicate of this bug: 974235
After some discussion with Timothy we realized that the results in comment 54 may have been obtained while async scrolling is in a "broken" state because of bug 965593 (see for instance bug 974081 for the sms app). So while the results above are technically valid for 1.3 *now* they do not represent what the user experience would be like if async scrolling weren't broken.
Bug 965593 has now been backed out, which should greatly improve the stutters/jittery behaviour that were noted in comment 54. It would good to have those tests re-done on a build that includes the backout as I suspect the results will be very different.
blocking-b2g: --- → 1.4+
Flags: needinfo?(clee)
Duplicate of this bug: 975967

Updated

5 years ago
Whiteboard: [c=handeye p= s= u=1.3] [apz_testrun][ETA:2/21] → [c=handeye p= s= u=1.4] [apz_testrun]
Duplicate of this bug: 982883
We need this patch for v1.3T.
Flags: needinfo?(styang)
Flags: needinfo?(jcheng)

Comment 61

5 years ago
Why is this needed for v1.3T? I don't think v1.3T uses APZC.
Uplifting this to 1.3 codebase would get most of Gecko and a large part of Gaia to 1.4 level.  That is a serious request.

Comment 63

5 years ago
As Milan said, this would involve basically updating to 1.4, which would delay us by many weeks at least. Why is this needed?
(In reply to James Zhang from comment #60)
> We need this patch for v1.3T.
Hi James,
APZC won't be enabled for v1.3T, it's not necessary. Thanks.
Flags: needinfo?(styang)
Flags: needinfo?(jcheng)
(In reply to Andreas Gal :gal from comment #63)
> As Milan said, this would involve basically updating to 1.4, which would
> delay us by many weeks at least. Why is this needed?

Fabrics think we can't disable it on v1.3t, see bug 985928
Blocks: 985928
Flags: needinfo?(gal)

Comment 66

5 years ago
I am counting 72 bugs that are implicated in this dependency tree. Cherry picking those would be a nightmare. And thats likely not all. I am sure we missed a few dependencies. This would add at least a month or two to the schedule trying to stabilize this. Its likely easier to abandon 1.3T and stabilize 1.4 for Tarako, but that would also add months of delays to the schedule. Steven, please do a coordination call to determine whether this bug is a blocker and if so, we should estimate a new schedule.
Flags: needinfo?(gal) → needinfo?(styang)
We are closing this meta bug as resolved fixed for 1.4. There are some app specific issues we are tracking as QC 1.4 CS blockers, and we have a correctness issue tracked in bug 984618, but this one can be closed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
SPRD disabled APZC for the evaluation.
Flags: needinfo?(styang)
You need to log in before you can comment on or make changes to this bug.