903374 - Black screen scrolling on Browser with zoom v1.1.0hd

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Geeksphone]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130803192641

Steps to reproduce:

Reproduced on Geeksphone Peak on 1.1.0hd version:
1) Open Browser app
2) Enter into any page, like http://forum.geeksphone.com
3) Increase the zoom of the page.
4) Scroll up and down to see the black screen issue.

Please threat it as hd+


Actual results:

When the page is repainted when scrolling, all browser shows a black screen for a few seconds.

We tested with gecko-18 and the problem not exists, only have the problem with v1.1.0hd gecko branch.


Expected results:

You can scroll normally without black screen when the page is repainted.

Comment 1

[Geeksphone]

The black screen issue only occurs with 1.1.0hd gecko branch, on master branch works fine.

Comment 2

[Alex Keybl [:akeybl]]

Tony, can you help expedite this through QA so that we determine whether this is device specific or common across devices on the hd branch? Thanks!

Comment 3

[Jason Smith [:jsmith]]

(In reply to Alex Keybl [:akeybl] from comment #2)
> Tony, can you help expedite this through QA so that we determine whether
> this is device specific or common across devices on the hd branch? Thanks!

Swaroopa - can you look into this?

Comment 4

[Swaroopa Vantipalli [:swaroopa]]

Attachment: Video

I tried the STR on helix device which is HD and the black screen on zooming is not reproducible.
Attached the video of how its seen on helix.

Build:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/b1d497ce9cce
Gaia   3126b65bc49838bcfae5737ca39be44d4865056f
BuildID 20130809042203
Version 18.0

Comment 5

[Alex Keybl [:akeybl]]

Hey Dylan, we're trying to better support GP as a pre-release population. Is there any way that an engineer can look at this on a Peak to double check whether there's anything we can do on our side before sending back to GP?

Comment 6

[Dylan Oliver [:doliver]]

Forwarding on for Tim to comment.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

FWIW I also didn't see this issue on the Peak when I was tested the HD branch with the now-uplifted patches on bug 879004 and bug 883646. Getting a video of the issue might help me narrow down the STR.

Comment 8

[ralph]

Is this the same Bug? --> https://bugzilla.mozilla.org/show_bug.cgi?id=902575

Comment 9

[Kartikaya Gupta (email:[e-mail])]

That one is on the master branch, and likely caused by my recent changees. Those changes are not on the HD branch and so cannot be responsible for this bug.

Comment 10

[Geeksphone]

In this URL you can see the exact bug.

https://www.dropbox.com/s/nvk0a2jac2hojgl/VID_20130813_172945.mp4

I try to upload here, but is a little bigger.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

If this doesn't happen on b2g18_v1_1 but happens on b2g_v1_1_0hd it must be related to dppx (and not Gaia).

(In reply to Geeksphone from comment #10)
> https://www.dropbox.com/s/nvk0a2jac2hojgl/VID_20130813_172945.mp4

I don't see the described behavior in the video though.

Comment 12

[Alejandro]

Hi, in the video provided by Geeksphone I can see the black screen in several occasions from 00:10 sec

If the problem seems not to be in Gaia - Gecko (?) - how should we proceed in order to find a solution?

Thanks
Alejandro

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alejandro from comment #12)
> Hi, in the video provided by Geeksphone I can see the black screen in
> several occasions from 00:10 sec
> 
> If the problem seems not to be in Gaia - Gecko (?) - how should we proceed
> in order to find a solution?

LOL, I clicked on the same link and it send me to a different video!

It's definitely not an Gaia issue because Gaia is not capable of generate this kind of defect.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

:nrc volunteered :BenWa for needinfo'ing.

Comment 15

[Nick Cameron [:nrc]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> :nrc volunteered :BenWa for needinfo'ing.

I realise this was probably a bad suggestion - I was thinking tiles, but that is not turned on yet for b2g. So, maybe azpc? Or a general layers issue? Going to change needinfo to kats since he was commmenting earlier and might be able to say if it is likely due to azpc. Otherwise probably just need someone with an HD phone to repro it in a debugger. Maybe pass to Milan for that.

Comment 16

[JMK]

We (geeksphone) can provide a Peak device if needed, if it helps to debug & fix the issue.
Thanks for your implication!

Comment 17

[Kartikaya Gupta (email:[e-mail])]

From the video this doesn't really appear to be an APZC issue; the fact that there is that small strip of displayed content always in the right place seems to indicate that the panning coordinates are correct throughout. I also don't think it's a problem with the displayport rect because of that displayed content - if the displayport was off you might see blackness on side of the display but not both like in the video. I'm not really sure what's going on here.

Can you provide a gecko and gaia changeset you see this on? I can build the HD branch for my Peak and see if I can reproduce it. Also if this is a recent regression then bisecting the changes to narrow down exactly when it started happening would be useful, in case I cannot reproduce the problem.

Comment 18

[Benoit Girard (:BenWa)]

Interesting, can you attach the adb logcat? We could find something interesting like an allocation failure. It's very strange that some parts of the content layer is still rendering.

Comment 19

[Geeksphone]

@Kartikaya

You can get the changesets from here: http://www.geeksphone.com/manifests/latest/source_peak-v1.1.0hd.xml  And use this manifest too.

Or download our latest images from http://downloads.geeksphone.com/

@Benoit

If you need it i will upload a full logcat, but i just take some logs when moving the screen and the bug is present.

I/IdleService(  118): next timeout 1000 msec from now
I/IdleService(  118): SetTimerExpiryIfBefore: next timeout 1000 msec from now
I/IdleService(  118): reset timer expiry to 1010 msec from now
I/IdleService(  118): Reset idle timeout: tell observer 446f4fa0 user is back
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
I/IdleService(  118): Get idle time: time since reset 14 msec
I/IdleService(  118): Idle timer callback: current idle time 14 msec
I/IdleService(  118): next timeout 984 msec from now
I/IdleService(  118): SetTimerExpiryIfBefore: next timeout 983 msec from now
I/IdleService(  118): reset timer expiry to 993 msec from now
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
I/IdleService(  118): Get idle time: time since reset 13 msec
I/IdleService(  118): Idle timer callback: current idle time 13 msec
I/IdleService(  118): next timeout 985 msec from now
I/IdleService(  118): SetTimerExpiryIfBefore: next timeout 985 msec from now
I/IdleService(  118): reset timer expiry to 995 msec from now
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
E/memalloc(  118): /dev/pmem: No more pmem available
W/memalloc(  118): Falling back to ashmem
I/IdleService(  118): Get idle time: time since reset 310 msec
I/IdleService(  118): Idle timer callback: current idle time 310 msec
I/IdleService(  118): next timeout 689 msec from now
I/IdleService(  118): SetTimerExpiryIfBefore: next timeout 689 msec from now
I/IdleService(  118): reset timer expiry to 699 msec from now
I/IdleService(  118): Get idle time: time since reset 1010 msec
I/IdleService(  118): Idle timer callback: current idle time 1010 msec
I/IdleService(  118): next timeout 298990 msec from now


We change the memory allocation and give all the memory we can to the GPU but we get the same logs.

Comment 20

[Alejandro]

Hi @Benoit, is Geeksphone information enough for your analysis? If not please ask them any detail you may need.

Thanks
Alejandro

Comment 21

[Benoit Girard (:BenWa)]

Yes, we're running out of pmem but the fall back to shared memory (ashmem) is not working it appears. This will need to be debugging manually.

Comment 23

[Geeksphone]

Any news on this?

Comment 24

[Geeksphone]

Attachment: 903374.patch

Backport of Bug https://bugzilla.mozilla.org/show_bug.cgi?id=869696

Comment 25

[Geeksphone]

This Backport, of bug https://bugzilla.mozilla.org/show_bug.cgi?id=869696 solves the issue.

Please review and add it to v1.1.0hd gecko branch.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 800040 [details] [diff] [review]
903374.patch

Review of attachment 800040 [details] [diff] [review]:
-----------------------------------------------------------------

Cwiiis is off for two months; passing the buck to bjacob who probably knows what was going on in the above-mentioned bug.

Comment 27

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 800040 [details] [diff] [review]
903374.patch

Review of attachment 800040 [details] [diff] [review]:
-----------------------------------------------------------------

r+ to the ShadowLayerUtilsGralloc.cpp changes, noting that this is identical to code we already have in mozilla-central, but r- to the rest of the patch seems accidental / unrelated: the Adreno 320 detection, and the strndup_impl changes.

::: gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp
@@ +252,5 @@
>                                            SurfaceDescriptor* aBuffer)
>  {
> +
> +  // Check for devices that have problems with gralloc. We only check for
> +  // this on ICS or earlier, in hopes that JB will work.

I see that we already have exactly that code in mozilla-central. This looks fine, so r+ to that. But to land this on b2g-18 you will need another kind of approval than just r+. And the other hunks in this patch, which look accidental, force me to r- this patch.

Comment 28

[Geeksphone]

Attachment: 903374-2.patch

Sorry about the accidental hunks on the old patch, but as you said, we only create this patch to port mozilla-central source to v1.1.0hd to solve the bug.

We tested that this patch has only the needed changes to solve this issue.

Please review it.

Comment 29

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 800181 [details] [diff] [review]
903374-2.patch

Review of attachment 800181 [details] [diff] [review]:
-----------------------------------------------------------------

Hey, you still have hunks in GLContext.cpp and GLContext.h that aren't used by what you are doing in ShadowLayerUtilsGralloc.cpp, so please consider dropping them, but that's OK, no need for another round of reviewing.

Comment 30

[Geeksphone]

(In reply to Benoit Jacob [:bjacob] from comment #29)
> Comment on attachment 800181 [details] [diff] [review]
> 903374-2.patch
> 
> Review of attachment 800181 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Hey, you still have hunks in GLContext.cpp and GLContext.h that aren't used
> by what you are doing in ShadowLayerUtilsGralloc.cpp, so please consider
> dropping them, but that's OK, no need for another round of reviewing.

We rechecked it. As you said, only ShadowLayerUtilsGralloc.cpp changes are needed to solve the bug.

Thanks for all.

Comment 31

[Robert Kaiser]

If all that's left here is the patch landing, could you set a checkin-needed keyword here and instruct which patch needs to be landed where?

Comment 32

[Robert Kaiser]

Assigning to the patch author. Geeksphone, can you please follow up on comment #31?

Comment 33

[Robert Kaiser]

From what I understand, this is a core patch, so this is to land in mozilla-central ultimately.

It might be a good idea to get this uplifted to Mozilla 26 (B2G 1.2) but let's get it into m-c first.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

IIUC, this is a backport of bug 869696 (which landed on Gecko25) for the v1.1hd branch only. At which point, this needs blocking-b2g:hd+ before it can land.

Comment 35

[Robert Kaiser]

OK, now that it has hd+, adding checkin-needed again.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/0f1ee7f92a79