1106909 - [System][Lockscreen] Notification Scrolling on the lock screen is slow to respond and choppy

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Martin Shuman [:Marty]]

Description:
If the user has received a number of notifications while their device was locked, the notifications (by default) will display in a scrollable list on the Lock Screen.  When the user scrolls this list, there is significant latency between user input and scrolling, and the scrolling refresh rate is low, causing the scrolling to look choppy.

Note: Scrolling the list of notifications in the Utility/Notification tray performs responsively and smoothly.

Repro Steps:
1) Update a Flame device to BuildID: 20141202040207
2) Ensure that the device has Lock screen enabled, and Notifications are shown on the lock screen (Found in Settings.  Both are on by default).
3) Press the power button to lock the device.
4) When viewing the lock screen, take 5 or more screenshots with Volume Down + Power Button to generate notifications.
5) Scroll the list of notifications up and down.
  
Actual:
Notification scrolling on the lock screen is slow to respond and appears choppy.
  
Expected: 
Notification scrolling on the lock screen is responsive and smooth.
  
Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141202040207 (Full Flash)
Gaia: 725685831f5336cf007e36d9a812aad689604695
Gecko: 2c9781c3e9b5
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
  
Repro frequency: 5/5
See attached: video clip (URL)

------------------------------------------------

This issue DOES occur on Flame 2.1.
Notification scrolling on the lock screen is slow to respond and appears choppy.

Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20141202001201 (Full Flash)
Gaia: ccb49abe412c978a4045f0c75abff534372716c4
Gecko: 18fb67530b22
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 1

[Peter Bylenga [:PBylenga]]

adding qawanted for branch checks.

Comment 2

[Cody Roesch [:croesch]]

Tested with Shallow Flash on 319mb using Engineering builds.

This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK, Flame v188-1 Base

Actual Results: Scrolling through notifications on the lockscreen is not smooth as would be expected.

Repro Rate: 10/10

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141203044002
Gaia: 984e6d79aa799d2695f9ca132dfdc1665a56c019
Gecko: a9fc46355661
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141203065100
Gaia: 5655269098c7e82254e56933f1af05b4abe2a2f3
Gecko: 86608c9389b5
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141202035701
Gaia: 8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko: 29222e215db8
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------------------------------------------------------------
Environmental Variables:
Device: V188-1 Base
BuildID: 20141021162107
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 3

[Joshua Mitchell (Inactive)]

NI to Lock-Screen screen owner for blocking call. Note: Not a regression

Comment 4

[Gerry Chang [:gchang]]

I test the same scenario in 1G mem, the scrolling on the lock screen is not that slow to respond and choppy. 
NI developer for this issue.

Comment 5

[Greg Weng [:snowmantw][:gweng][:λ]]

John: is this the SVG issue we discussed once?

Comment 6

[John Lu [:mnjul][Please NI or I'll miss]]

Yep -- bug 1023500 comment 17. Not sure what we can do though.

Comment 7

[John Lu [:mnjul][Please NI or I'll miss]]

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #6)
> Yep -- bug 1023500 comment 17. Not sure what we can do though.

Other than removing the alpha gradient mask, I mean.

Comment 8

[Greg Weng [:snowmantw][:gweng][:λ]]

NI Jerry for the possibility of profiling graphic performance of (maybe) SVG. We don't know how to profile it properly to see if the problem is caused by SVG.

Comment 9

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Ethen is looking for this issue now.

Comment 10

[Ethan Lin[:ethlin]]

We found the most time wasting part is the svg mask. I create another bug 1116070 for svg mask performance. In short term, I think there are two ways to speed up the notification scroll.
1. Don't use svg mask. Try to use alpha masks.
2. The translucent part is only on the top and bottom and size is 20% of the area. Is there any way to set mask separately and only apply the 20% area? I am not sure if this is possible.

Comment 11

[Greg Weng [:snowmantw][:gweng][:λ]]

John, what's your opinion?

Comment 12

[Greg Weng [:snowmantw][:gweng][:λ]]

And I believe we need UX' opinion for this bug.

Comment 13

[John Lu [:mnjul][Please NI or I'll miss]]

The opacity-gradient transition (gradually transitioning from fully opaque to fully transparent) is a UX requirement so unless there is any other way to achieve it than using the svg mask, it's not up to me to decide.

Applying separate masks sounds nice but AFAIK CSS does not allow multiple masks to be assigned to one element; i.e. there is no 
{
 masks: url('aaa.svg'), url('bbb.svg')
}

Would be nice if we could have it though (and if it does improve performance quite much).

Comment 14

[Cameron McCormack (:heycam)]

(In reply to Ethan Lin[:Ethan] from comment #10)
> We found the most time wasting part is the svg mask. I create another bug
> 1116070 for svg mask performance. In short term, I think there are two ways
> to speed up the notification scroll.
> 1. Don't use svg mask. Try to use alpha masks.

You can make SVG masks use the alpha channel:

  <linearGradient id="g">
    <!-- stop-color doesn't matter, just the alpha channel does -->
    <stop offset="0" stop-color="black" stop-opacity="1"/>
    <stop offset="1" stop-color="black" stop-opacity="0"/>
  </linearGradient>
  <mask mask-type="alpha">
    <rect ... fill="url(#g)"/>
  </mask>

Comment 15

[Stephany Wilkes]

Greg, please elaborate on the UX input needed in comment #12. I've read the thread but am not sure what UX input is needed on - thanks!

Comment 16

[Greg Weng [:snowmantw][:gweng][:λ]]

For UX I think the point is, according to the earlier discussions of implementing this feature, UX & PM both felt the performance downgrade John and me had actually warned is acceptable (bug 1023500 comment 17 as John commented, and as bug 1023500 comment 43 he mentioned again; I also warned it at bug 1023500 comment 14). So, if there is anything we NOW feel it's a bug, we should better to let UX confirm whether it's acceptable or not again. As developers we of course could fix things, but to fix a bug that wasn't a bug and even endorsed by decision makers is questionable. And this would make to workaround it in Gaia while the real Gecko work is ongoing become unreasonable, unless the workaround is small and neat enough, since when Gecko work done we may already change change the implementation, and LockScreen is really barely to accept workarounds tricks DOM & CSS rules unless the original implementation is wrong.

Comment 17

[Stephany Wilkes]

In bug #1023500, both UX team members (Rob and Amy) gave it ui-review-. Where did UX (Rob and Amy) say that the performance downgrade was acceptable in bug #1023500? 

Please note I am slow to reply as I’m on PTO in Mexico with slow-to-no Internet depending on the moment.

Comment 18

[Stephany Wilkes]

Also ni? Amy on this as back-up while I'm on PTO.

Comment 19

[Greg Weng [:snowmantw][:gweng][:λ]]

(Now John is back. I'll left the major discussion to him)

Status updated:

0. Stephany: please note the UI- is for the alignment issue (see Bug 1023500 Comment 58) which had been fixed in Bug 1038502. It's irrelevant to the performance issue John and I had asked at Bug 1023500 Comment 14 and Bug 1023500 Comment 43.

1. Why I asked to identify this is a bug is that I'm afraid we landed a feature that PM & Devs said OK with the performance downgrade while UX never said OK, which apparently violated some policies. John, could you clarify the situation while the bug was ongoing and finally we decided to land it with the downgrade?

2. Graphic team said that there are two major performance issues here: one is the SVG mask that they have some WIP solutions; another one is the scrolling itself is slow, and the root cause is things in System app wouldn't be accelerated via APZ because only OOP frames would be rendered with APZ. They've had a meeting for that and the conclusion is this probably be fixed at Feb. So the question is whether it's worth to put resources on Gaia to make the notification area as an OOP frame in the name of the performance. However, I think that we should:

a). Test scrolling without SVG is OK for both UX and QA (it's not 60FPS even without the mask)
b). If not, apparently the major issue is APZ, then we need to decide to wait Graphic team or we need to implement the OOP notification frame

Of course the premise is we first identify the bug *is* a bug as I said.

Comment 20

[Greg Weng [:snowmantw][:gweng][:λ]]

(and what I mean is it's a bug should have a *proper* Gaia fix, not just workaround the platform issue as I said)

Comment 21

[Stephany Wilkes]

I'm clearing the UX flag here, as it sounds like we need to approve performance downgrade in another bug. It's too hard to follow here.

Comment 22

[BMO Automation]

Firefox OS is not being worked on