### ENV Device Nexus 5 Gaia defe57f89ef5f6d51a6d0ac0815ff6ce0367b50d Gecko 82a055c447b89f1db919a0f617e7a8b39f6ef584 BuildID 20140121110525 Version 29.0a1 ### STR 1. launch app (Gallery, Maketplace) 2. scroll down ### Expected the screen can scroll down ### Actual black screen

ni? schiu on this bug for comments

I only reproced in old code base(several days) ago, and disabling APZ seems help. However I cannot reproduce this issue in the today code. I may need to do some bisecting work.

clear NI regards to last comment

clear NI regards to comment 3

Hi Askeing, can we confirm reproducibility of this bug on latest build? thanks

Hi Milan, is it a APZ bug that had been fixed?

It's possible, a number of bugs that sound like this have been taken care of.

I'm not sure offhand of any APZ bug that was fixed recently and that matches the symptoms shown in the video. Is this fix something that needs uplifting? Or can this bug just be closed WFM?

After test the gallery app, it still can reprodce on latest Nexus 5 KK build. ### STR 1. launch camera app, take lots of photos. 2. close all apps. 3. launch gallery app, scrolling the screen.

Just discussed with QA and dumping the layer with LayerScope. The content of all layers is correct, however the composted screen seems not right. Will check from the compositor relative functions first.

Add ETA to whiteboard after discussing the issue with Solomon.

The gallery app black screen is likely the same issue that is being investigated in bug 965389 (last few comments). With the patch I just landed in bug 965945 the gallery app will probably crash instead of showing the black screen until we fix the root cause.

Just confirmed with my nexus-5 + KK, this issue was gone after disabling APZ(reboot needed to take effect). Meanwhile the application "Setting" also has the same problem.

Discussed with Milan on IRC, keep a note here: milan: "works with apz off" does not actually mean it's an apz bug milan: the layout and layers is often different when apz is on, which leads into discovering bugs in different places milan: in this case, isn't it a 4k texture limit?

Discussed with Milan on IRC, keep a note here: milan: solomon should definitely look at bug 975033 and see if it's the same issue

Also I put up a gaia patch on bug 965389 which might fix it for the gallery app.

The patch of bug# doesn't help on Nexus-5+KK. From the uploaded video #3 you can see: besides the black screen problem, the thumbnails also be enlongated after the device rotation(landscape to portrait). The same problem also can be found in Nexus-4 + JB, and after disabling APZ the problem is disappear.

Kats, When I added log on creation of GrallocBufferActor to observe the dimension of texture, the black screen seems dedicated to the large texture allocation(> 4k) problem while enabling APZ. Would you please help to look into this issue? Thanks.

Can you confirm that the build you are testing has the fix from bug 965389? It just merged into gaia master yesterday. Also, if you're getting a >4k texture allocation in GrallocBufferActor, then you should be hitting the code at [1] and the gallery app should be crashing, not showing black screens. The underlying cause might just be because the Nexus 5 has a huge screen resolution, and our normal displayport multipliers put it over the texture size. If so, you can try reducing the displayport multipliers to confirm - set the apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier prefs to "2.0" and see if the problem goes away. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp?rev=5ac5ee30517d#298

qawanted to retest with commit mentioned in comment 22.

Hi Solomon, While QA is retest it, would you please also try the suggestion from Kats in comment 22?

Reassign the bug back to Solomon for trying the suggested solution in comment 22.

Solomon, Please verify kart's suggestion on comment 22. I think that should work. Assign back to you. You can either 1. apz.y_stationary_size_multiplier prefs to "2.0" for device which resolution is equal or higher then HD. 2. Setup an upper bound in code. Depend on screen resolution, reduce multiplier in code to make sure texture allocation is under 4K.

Ivan, Since this problem appear only on HD or higher resolution device. Is it really a blocker for 1.4?

(In reply to C.J. Ku[:CJKu] from comment #27) > Ivan, > Since this problem appear only on HD or higher resolution device. Is it > really a blocker for 1.4? Is the resolution of the Nexus 5 comparable to any existing supported production device (e.g. ZTE Open C, Reference Device)?

(In reply to Jason Smith [:jsmith] from comment #28) > (In reply to C.J. Ku[:CJKu] from comment #27) > > Ivan, > > Since this problem appear only on HD or higher resolution device. Is it > > really a blocker for 1.4? > > Is the resolution of the Nexus 5 comparable to any existing supported > production device (e.g. ZTE Open C, Reference Device)? As far as I know, no. Open C is qHD.

(In reply to C.J. Ku[:CJKu] from comment #29) > (In reply to Jason Smith [:jsmith] from comment #28) > > (In reply to C.J. Ku[:CJKu] from comment #27) > > > Ivan, > > > Since this problem appear only on HD or higher resolution device. Is it > > > really a blocker for 1.4? > > > > Is the resolution of the Nexus 5 comparable to any existing supported > > production device (e.g. ZTE Open C, Reference Device)? > As far as I know, no. Open C is qHD. Open C is WVFG (800x480) Reference device is FWVGA (854x480) For the existing supported production device, there is no resolution in HD or higher.

I confirmed that setting apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier to 2.0 works in Nexus-4, and will discuss with Morris for feasible ways(individual prefs for devices or do calculation in AsyncPanZoomController.cpp).

How about the result in Nexus 5? I am asking because the resolution is different between Nexus 4 (HD, 768 x 1280) and 5 (full HD, 1080 x 1920). Should we verify it on Nexus 5 as well before going for proper solution (individual prefs for devices or do calculation in AsyncPanZoomController.cpp)

Morris also confirmed that setting apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier to 2.0 also works in Nexus-5.

WIP: This patch works for nexus-4, will update the result of nexus-5.

Change the nexus-4's prefs(apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier) in build-time as a short term solution. Will seek for solutions in APZ's function to calculate more accurate ratio.

Change the nexus-5's prefs(apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier) in build-time as a short term solution. Will seek for solutions in APZ's function to calculate more accurate ratio.

Since Mwu is in MWC now, anyone else can do the review?

(In reply to Kevin Hu [:khu] from comment #37) > Since Mwu is in MWC now, anyone else can do the review? Kats got it. Also, these aren't valid patches to fix the issue.

(In reply to Michael Wu [:mwu] from comment #38) > (In reply to Kevin Hu [:khu] from comment #37) > > Since Mwu is in MWC now, anyone else can do the review? > > Kats got it. Also, these aren't valid patches to fix the issue. We know these patches are not ideal solutions, however due to this issue is a blocker of 1.4+(by 2/28), we might have to use these patch as short term solution. Meanwhile Jerry Shih is trying another idea to see if it works. We would appreciate it if you could kindly provide us recommendations of alternative way for this issue.

How about this patch? I limit the maximum display port size. Let the size under 4096*4096. The patch attachment 8378367 [details] [diff] [review] in bug 965945 sets a 4096 limit size.

use std::floor() to make sure that the size is less than 4096 device pixel.

(In reply to Solomon Chiu [:schiu] from comment #39) > (In reply to Michael Wu [:mwu] from comment #38) > > (In reply to Kevin Hu [:khu] from comment #37) > > > Since Mwu is in MWC now, anyone else can do the review? > > > > Kats got it. Also, these aren't valid patches to fix the issue. > > We know these patches are not ideal solutions, however due to this issue is > a blocker of 1.4+(by 2/28), we might have to use these patch as short term > solution. Meanwhile Jerry Shih is trying another idea to see if it works. We > would appreciate it if you could kindly provide us recommendations of > alternative way for this issue. This is neither a long term nor near term solution since it only affects Nexus 4/5 devices. We need a solution that works for everyone.

Comment on attachment 8382065 [details] [diff] [review] Set prefs for APS's multiplier in Nexus-4 Review of attachment 8382065 [details] [diff] [review]: ----------------------------------------------------------------- Fixing this per-device is not a good idea.

Comment on attachment 8382121 [details] [diff] [review] limit_display_port.patch v2 Review of attachment 8382121 [details] [diff] [review]: ----------------------------------------------------------------- This fix doesn't work in many cases, particularly when you have any level of zoom applied, because the resolution is not considered at all. It's also the wrong place to be putting this check. I have a patch on bug 975033 which is similar to this but puts the check in a better place. It needs more testing before I can ask for review on it, but I will try to do that today if a fix for this problem is needed soon. For now I'll just make this bug depend on that one.

Also adding a direct dependency on bug 957688 because that is the correct fix for this. Bug 975033 is just a short-term workaround.

Wrong bug number. Sigh.

Hi Kats, Thanks for your help on this. If the patch in your bug 975033 works, do we need to work on any patch in this one? If not, I wonder if we can consider to mark this bug as the duplicate of bug 975033. Or you think it is more appropriate to just keep the dependency and try to resolve it by 2/28. What do you think?

If the patch on bug 975033 works (which I think it should, but don't have a Nexus 5 to verify) then yeah we can dupe this bug over to that one. I generally prefer leaving it as a dependency until the patch has actually landed in case it doesn't pass review and we change the approach, in which case it might not fix this.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #48) > If the patch on bug 975033 works (which I think it should, but don't have a > Nexus 5 to verify) then yeah we can dupe this bug over to that one. I > generally prefer leaving it as a dependency until the patch has actually > landed in case it doesn't pass review and we change the approach, in which > case it might not fix this. I think it could be helpful to send your patch to Solomon for a quick verification on Nexus 5. If this works for you, please let him know how to get your patch and apply it for the verification.

The patch is at https://bug975033.bugzilla.mozilla.org/attachment.cgi?id=8382332 - it's a Gecko patch, feel free to apply and let me know how it works.

Hi Solomon, Kats has the patch from bug 975033 for resolving the similar issue in this bug. Please help to get the patch mentioned in comment 50 and try it in Nexus 5 to see if it works as expected. Thank you.

The one in comment 50 is obsolete. Please grab the latest patch from bug 975033 directly.

(In reply to Ivan Tsay (:ITsay) from comment #51) > Hi Solomon, > > Kats has the patch from bug 975033 for resolving the similar issue in this > bug. Please help to get the patch mentioned in comment 50 and try it in > Nexus 5 to see if it works as expected. Thank you. We just verified the patch that Kats provided in 975033 works fine in Nexus-5. Kats, Can I set this bug as duplicating to 975033 ?