Closed Bug 1007119 Opened 10 years ago Closed 10 years ago

[flame] white drawing area problem on setting app

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g 2.0+

People

(Reporter: sotaro, Assigned: BenWa)

References

Details

Attachments

(4 files)

screen shot of the stable checkerboarding
28.34 KB, image/png
Details
logcat with layer dump when the problem happens
1.66 MB, text/plain
Details
screen shot of the stable checkerboarding 2
11.80 KB, image/png
Details
Filtered logcat from attachment 8418780
3.07 KB, text/plain
Details 
On flame device, I saw a checkerboarding problem on setting app. I confirmed on b2g v1.4 flame and master flame.

*STR
[1] Start setting app
[2] Scrolling up and down until seeing checkerboarding

The checkerboarding sometimes becomes stably appear even after scrolling stopped.
Screenshot of one pattern of the stable checkerboarding.
When APZ and tiling is disabled, the checkerboarding does not appear. But scrolling performance is too bad.
Do you see this with APZ enabled and tiling disabled? I saw something similar while I was playing around with low-res tiling but couldn't reproduce it and wasn't sure what was going on.
I'm not able to reproduce this on a Flame running master; do you have more specific STR, or a video? Is this easy to reproduce? Like kats asks, does this happen with tiling disabled? Does this happen with layers.overzealous-gralloc-unlocking set to true?
Flags: needinfo?(sotaro.ikeda.g)
Got a profile of the setting app scrolling. I checked the profile with jeff. We can not find a bad thing in the profile. 
http://people.mozilla.org/~bgirard/cleopatra/#report=d5cde7999e84eca7ecf7e5e068a8ca6fa4888c2a
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> Do you see this with APZ enabled and tiling disabled? I saw something
> similar while I was playing around with low-res tiling but couldn't
> reproduce it and wasn't sure what was going on.

After the daily meeting, I am going to check it.
Flags: needinfo?(sotaro.ikeda.g)
Summary: [flame] Checkerboa​rding problem on setting app → [flame] white drawing area problem on setting app
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> Do you see this with APZ enabled and tiling disabled? I saw something
> similar while I was playing around with low-res tiling but couldn't
> reproduce it and wasn't sure what was going on.

I checked it. The problem happened only [APZ=ON,TILING=ON] case on master flame(yesterday's code).

-[1] APZ=ON,TILING=ON: problem happen
-[2] APZ=ON,TILING=OFF: problem does not happen. Rarely saw checkerboarding.
-[3] APZ=OFF,TILING=ON: problem does not happen.
-[4] APZ=OFF,TILING=OFF: problem does not happen. But scrool is very very slow.
Sometimes, it is difficult to reproduce. Once it happened, it seems easier to reproduce the problem.
This seems to confirm what I suspected, that it's a correctness issue in the tiling code.
Blocks: b2g-tiling
Component: Panning and Zooming → Graphics: Layers
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> Created attachment 8418780 [details]
> logcat with layer dump when the problem happens

The last state of the screen is like attachment 8418787 [details].
(In reply to Chris Lord [:cwiiis] from comment #4)
> I'm not able to reproduce this on a Flame running master; do you have more
> specific STR, or a video? Is this easy to reproduce? Like kats asks, does
> this happen with tiling disabled? Does this happen with

Reproducing the problem is not easy, but not too hard. I tried to scroll as quickly as possible. One scroll is relatively long step. Sometime try to scroll until top/bottom. Sometimes changed the scroll direction before reaching top/bottom.
> 
> -[1] APZ=ON,TILING=ON: problem happen
> -[2] APZ=ON,TILING=OFF: problem does not happen. Rarely saw checkerboarding.
> -[3] APZ=OFF,TILING=ON: problem does not happen.
> -[4] APZ=OFF,TILING=OFF: problem does not happen. But scrool is very very
> slow.

When I tried the last time, [APZ=OFF,TILING=OFF] was very very slow. I can not reproduce this symptom anymore :-(
The log looks normal, except for the very very last layer dump, where the displayport for layer 0xaff09c00 is at y=642 and so will not contain the visible area. Every frame up to that last frame doesn't have this problem though.
Actually, a little more interesting is how the scroll position of that layer jumps from the bottom of the page to top of the page abruptly (see where it goes from y=1585.33 to y=0) near the end of the dump. That looks like content (or something else) did a scrollTo but there isn't enough info in the log to say what happened there.
Actually the shadow-transform on the thebes layer under it also jumped by a lot between those two frames so that might just be laggy painting. (i.e. you panned from the bottom to the top and the APZC kept updating the shadow transform, and then when the repaint came in at the top of the page both the viewportScroll and the shadow transform got updated).

So yeah, other than that very last frame I don't see much wrong in this log.
How does Flame do with the gfxtestapp and all the tiling, etc.?  Passes?
(In reply to Sotaro Ikeda [:sotaro] from comment #7)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> > Do you see this with APZ enabled and tiling disabled? I saw something
> > similar while I was playing around with low-res tiling but couldn't
> > reproduce it and wasn't sure what was going on.
> 
> I checked it. The problem happened only [APZ=ON,TILING=ON] case on master
> flame(yesterday's code).

I updated the master flamce code to today's one(next day). I sometimes saw a checkerborading. But I did not saw the stable white region anymore.
It seems better to set INVALID unless the problem happen again.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Sorry, I reopen again. Temporary white region is still present. White the temporary white region is too big as a temporary checkerboarding.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Sotaro Ikeda [:sotaro] from comment #21)
> Sorry, I reopen again. Temporary white region is still present. White the
> temporary white region is too big as a temporary checkerboarding.

Even temporary white region, it become more difficult than yesterday's rom.
By using the rom created from today's source code, the problem happened relatively easily.
kats, this bug is the bug that I shows you.
blocking-b2g: --- → 2.0?
I spent some time trying to reproduce this and I was unable to using the latest m-c code on Flame. If you ever find reliable STR please let me know.
Okey, this bugs reproducibility seems very different depend on the ROMs.
On recent master flame device, it becomes hard to reproduce the problem. But on recent master hamachi, the problem becomes easier to reproduce.

*STR
[1] Start setting app
[2] Scroll to the middle of the page.
[3] Flip until the bottom.
[4] Flip long flip (the page scroll up to about middle of the page)

continue [3] [4] until the problem happens. Start next flip. Flip speed was relatively rapid. Basically do not wait flip stop in flip up case. In flip bottom case, scroll stop on the bottom.
Right - because of the "flywheel scrolling" feature for 2.0, if you fling within half a second of a previous fling, the speed will accumulate.  That way, you can go a lot faster than before, so you can get to the pieces that aren't ready a lot more often.  Low res tiling should help here.
(In reply to Milan Sreckovic [:milan] from comment #28)
> Right - because of the "flywheel scrolling" feature for 2.0, if you fling
> within half a second of a previous fling, the speed will accumulate.  That
> way, you can go a lot faster than before, so you can get to the pieces that
> aren't ready a lot more often.  Low res tiling should help here.

This checkerboarding should be temporary only. The thing Sotaro showed me last week was perma-checkerboarding.
OK, yes, I've seen that one.  That was definitely not checkerboarding, in the sense that "it'll come in just wait".
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → bgirard
I tested latest master hamachi and v1.4 hamachi. v1.4 hamachi seems easier to reproduce the problem. I can relatively easily reproduced the problem on the following STR.

- [1] start system app
- [2] scroll top to bottom several times relatively quickly.
- [3] sometimes put the setting app to background and return to homescreen app.
      Then soon set the setting app to foreground again by tapping setting app's icon.
- [4] soon re-start scrolling again.

continue[2]-[4] until the problem happens.

on master, low resolution rendering is enabled, the symptoms are different. I did not saw long time white drawing area except a few times. But I saw white flash and a kind of flickering relatively often.
By the STR in comment 31, I also often saw the white screen that seems to continue very very longtime(inifinity?) on v1.4 hamachi. It might be better not to enable network communication to test this. status bar's update could stimulate the screen update.
Sotaro, do you still see this on 2.0?
(In reply to Milan Sreckovic [:milan] from comment #33)
> Sotaro, do you still see this on 2.0?

I do not see the problem on b2g v2.0.
Thanks Sotaro.  No-Jun, if you don't see this either on 2.0 (or trunk) we can close it as WFM.
Flags: needinfo?(npark)
(In reply to Milan Sreckovic [:milan] from comment #35)
> Thanks Sotaro.  No-Jun, if you don't see this either on 2.0 (or trunk) we
> can close it as WFM.

I do not see it in Flame/Buri with latest 2.0.  Will close with WFM as advised.

Version tested:
Gaia      de77f794db22a45f9d575de2c6e266a30a50de3b
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/79712bd7b60d
BuildID   20140625000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Flags: needinfo?(npark)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: