1041971 - Low precision scrolling artifacts are too obvious on the homescreen

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect, P1)

Description

[Kevin Grandon :kgrandon]

We should disable low precision opacity as currently scrolling the vertical homescreen is pretty bad.

Comment 1

[Kevin Grandon :kgrandon]

Attachment: 0001-Bug-1041971-Disable-low-precision-opacity-r-kats.patch

Kats - are you ok if we disable this for now? It's causing way too many artifacts on the vertical homescreen during scroll.

Comment 2

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

Comment on attachment 8460095 [details] [diff] [review]
0001-Bug-1041971-Disable-low-precision-opacity-r-kats.patch

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

Define "way too many artifacts". I don't think we can disable this without finding a different solution for the problem it's fixing. I'm actively working on that.

Also note that there was a regression over the weekend (bug 1041608) which gets a bunch of stuff stuck in low-precision mode. That makes this problem much more obvious, but disabling low-precision opacity won't fix that because it will still be in low-precision mode and it will still be very visible. Unless you have a strong argument I'm going to say no for now and continue my investigation into ways to fix this properly.

Comment 3

[Kevin Grandon :kgrandon]

Kats - I guess the problem is that the opacity of the icons make this way to visible. Hold two devices next to each other, each with ~50 icons on the vertical homescreen, one at 1.0 opacity, and one at 0.5. You'll see that scrolling the one with the opacity change is much more jarring than without. Making every element go to this opacity state is just not good UX.

The problem that we're fixing is that we can't use the scrolling opacity on the vertical homescreen because the scrolling just looks bad with it. What do you suggest we do?

Comment 4

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

I'm looking at options to disable the opacity change in some cases based on heuristics.

Comment 5

[Kevin Grandon :kgrandon]

To clarify, I realize about the bug where we currently get stuck in low-precision mode, this patch assumes that works correctly and was tested on a working 2.0 build.

Comment 6

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

Ok, thanks. If I can't figure out a good way to deal with this problem then I'll let you know and we can disable the opacity change.

Comment 7

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

I have new patches up on bug 1038416 which have the effect of disabling the opacity change on the homescreen. Do you mind giving that a whirl and let me know if that satisfies the requirements for this bug?

Comment 8

[Mason Chang [Inactive] [:mchang]]

Just tested the patches 1038416 on a nexus 4. Partner said that this is better than the current situation and is a good first step.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's also make sure we have an explicit option to disable low res tiling.  Shouldn't stop us from improving the heuristics, but we want to be able to just disable it.  Kats, if we need another bug for that, can you create one?

Comment 11

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

(In reply to Mason Chang [:mchang] from comment #8)
> Just tested the patches 1038416 on a nexus 4. Partner said that this is
> better than the current situation and is a good first step.

Did they mention any further steps or improvements? (With respect to the low-precision artifacts, as opposed to just "checkerboard less").

(In reply to Milan Sreckovic [:milan] from comment #9)
> Let's also make sure we have an explicit option to disable low res tiling. 
> Shouldn't stop us from improving the heuristics, but we want to be able to
> just disable it.  Kats, if we need another bug for that, can you create one?

Filed bug 1042152 for it.

Comment 12

[Jason Smith [:jsmith]]

Kevin - Can you weigh in on whether we need to block on this or not? I'm trying to understand the severity of user impact if we do not fix this.

Comment 13

[Kevin Grandon :kgrandon]

(In reply to Jason Smith [:jsmith] from comment #12)
> Kevin - Can you weigh in on whether we need to block on this or not? I'm
> trying to understand the severity of user impact if we do not fix this.

From what I understand bug 1038416 also fixes this and is blocking 2.0. Maybe we don't need to block here?

Comment 14

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

I would like to dupe this bug 1038416. Any objections? Is there anything the partner brought up that isn't resolved by 1038416?

Comment 15

[Mason Chang [Inactive] [:mchang]]

Let me test and ask the partner.

Comment 16

[Kevin Grandon :kgrandon]

Seems like bug 1038416 should solve this. Mason - feel free to reopen if needed.

Comment 17

[Mason Chang [Inactive] [:mchang]]

I just asked the partner and we still see low res tiling a bit too much. One suggestion they brought up would be to have some way to cache more of the displayport or tiles as their device will have more memory. Thus, we could still scroll up / down without checkerboarding / low res tiling. Kats, is there anyway to do this?

Comment 18

[Mason Chang [Inactive] [:mchang]]

Current initial good targets are scrolling 50 icons on the homescreen would be acceptable, 100 icons on the homescreen without checkerboarding or low precision tiling would be ideal.

Comment 19

[Kevin Grandon :kgrandon]

(In reply to Mason Chang [:mchang] from comment #18)
> Current initial good targets are scrolling 50 icons on the homescreen would
> be acceptable, 100 icons on the homescreen without checkerboarding or low
> precision tiling would be ideal.

It seems you can fit around 9 or 10 icons per "page" of the vertical homescreen. Is having 5 or 6x displayport height possible for higher memory devices? For their ideal situation we'd need 11x or higher which seems like it may be difficult to achieve.

Comment 20

[Mason Chang [Inactive] [:mchang]]

Another request, is it possible that we could have application specific displayport sizes? If not, the homescreen is the first priority.

Comment 21

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

(In reply to Mason Chang [:mchang] from comment #20)
> Another request, is it possible that we could have application specific
> displayport sizes? If not, the homescreen is the first priority.

I'm opposed to doing this, partly because it's harder and partly because exposing this to apps leaves it open to abuse just like will-change. I don't think that will end well. Also the benefit of doing this is not much because there's only one active app at a time anyway and only the active app actually uses the extra memory for displayport. If we can do it in one app then we can do it in all apps.

We can certainly increase the size of the displayport overall, there are prefs that can be tweaked. I'd rather do it on a per-device basis (via a #define, or just per-device prefs) if it comes down to that.

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

If a preference for the display port multipliers is required, please give us a separate bug on that and CC me.  I will run it through product and see if we can deal with it for 2.1

Comment 23

[Mason Chang [Inactive] [:mchang]]

I just spoke with kats and it looks like we have a preference for display port multipliers already here:

http://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?from=AsyncPanZoomController.cpp#301

Jeff, can you please try changing the 2 Y axis displayport preferences to something bigger? The preferences are:

apz.y_skate_size_multiplier - The current default value is 2.5, try changing it to 5.
apz.y_stationary_size_multiplier - The current default value is 3.5, try changing it to 5.

The default values are here:
http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPrefs.h?from=gfxPrefs.h&case=true#170

You can change preferences here: https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences

I tried changing both the skate multiplier and the y stationary size multiplier to 5, and from my human eyes, I couldn't see any low res tiling on a nexus 4 on the default gaia test homescreen. Jeff, can you please try?

Thanks!

Comment 24

[Milan Sreckovic [:milan] (needinfo for best results)]

Actually, on B2G, the default for Y size multipliers are 1.5 (skate) and 1.8 (stationary).
Also, when the width of the content fits on the screen, the X size multipliers (default 1.25 and 1.5) are combined into this.  So, changing these values to 5 means that you're getting a display port which is 7.5x or 6.25x the height of the screen.

Comment 25

[Kevin Grandon :kgrandon]

I suppose we are happy with the current state now?

Comment 26

[Mason Chang [Inactive] [:mchang]]

I guess we can close this bug for now. The displayport is bigger, and checkerboard less, but the partner said that FPS has dropped as a result. I asked them to continue tweaking the displayport size to their liking, so we may have to open a new bug if tweaking doesn't work for them. Thanks for looking into this Kevin!