Closed Bug 1041971 Opened 5 years ago Closed 5 years ago
Low precision scrolling artifacts are too obvious on the homescreen
We should disable low precision opacity as currently scrolling the vertical homescreen is pretty bad.
Kats - are you ok if we disable this for now? It's causing way too many artifacts on the vertical homescreen during scroll.
Attachment #8460095 - Flags: review?(bugmail.mozilla)
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.
Attachment #8460095 - Flags: review?(bugmail.mozilla) → review-
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?
I'm looking at options to disable the opacity change in some cases based on heuristics.
OS: Mac OS X → Gonk (Firefox OS)
Priority: -- → P1
Hardware: x86 → ARM
Whiteboard: [systemsfe] → [systemsfe][c=effect p= s= u=]
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.
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.
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?
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.
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?
5 years ago
Duplicate of this bug: 1041975
(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.
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.
(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?
I would like to dupe this bug 1038416. Any objections? Is there anything the partner brought up that isn't resolved by 1038416?
Let me test and ask the partner.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?] → [VH-FL-blocking-][VH-FC-blocking-]
Seems like bug 1038416 should solve this. Mason - feel free to reopen if needed.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1038416
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?
Status: RESOLVED → REOPENED
Flags: needinfo?(mchang) → needinfo?(bugmail.mozilla)
Resolution: DUPLICATE → ---
Summary: Low precision scrolling artifacts are too obvious → Low precision scrolling artifacts are too obvious on the homescreen
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.
(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.
Another request, is it possible that we could have application specific displayport sizes? If not, the homescreen is the first priority.
(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.
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
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!
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.
I suppose we are happy with the current state now?
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → WONTFIX
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!
You need to log in before you can comment on or make changes to this bug.