Closed Bug 978588 Opened 10 years ago Closed 9 years ago

[Notifications] Animating the utility-tray smoothness depends on the number of notifications

Categories

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

defect

Tracking

(tracking-b2g:backlog)

RESOLVED DUPLICATE of bug 1178162
tracking-b2g backlog

People

(Reporter: vingtetun, Unassigned)

References

Details

(Whiteboard: [systemsfe], [priority])

Attachments

(1 file)

With a few notifications, trying to drag the utility tray (the bar at the top of the screen) is smooth and easy.

As soon you have a few notifications it starts to become slower and slower. Looking at a profile (http://people.mozilla.org/~bgirard/cleopatra/#report=8dfa4fd85c2e9543dadbf3fdd522e955345fb9fb) it seems like we are spending our time into CSS::ProcessRestyle.

Since we are promoting notifications with a brand new shiny API I suggest that we block on that for 1.4.

The notifications are contained basically in a div with overflow-y: scroll.
Each time the finger is moved on the screen |div.style.transform = 'translateY(' + y + 'px)| is updated. The idea is to have the utility tray following the finger.

Asking dbaron is there any 'magic' way of avoiding the CSS::ProcessRestyle in this case.

In the worst case we will have to do some Gaia tricks to not really move the notifications <div> on the screen, but instead a -moz-element view of it.
Forgot to CC'ed dbaron.
Flags: needinfo?(dbaron)
I tried to use -moz-element in order to see if it helps. With 250 notifications it makes pan as smooth as the regular pan.

There is still a jank when the utility-tray is already opened and the user start to pan from the bottom to close the tray, but there is no jank when opening the tray.


The close-from-bottom jank probably comes from the change in the z-index order and toggling the visibility of the element that contains the background: -moz-element rule.

I think it's hard to get rid of all the jank but maybe it can be minimized a little bit.


Asking feedback to gerard-majax as I looking forward for someone to turn the POC into a real patch if there is no platform magic to do.

Needinfo gwagner just in case gerard-majax has something else to do (which is likely) but Gregor has someone handy.
Attachment #8384355 - Flags: feedback?(lissyx+mozillians)
Flags: needinfo?(anygregor)
The jank should likely be cheaper once I reland bug 971006 as well.
Vivien, what's the status of this patch regarding the notification tray rework being done ?
(In reply to Alexandre LISSY :gerard-majax from comment #4)
> Vivien, what's the status of this patch regarding the notification tray
> rework being done ?

That does not change anything. The expensive parts are mostly on the platform side and re-working / re-factoring the code on our side will not change this as long there is a big DOM.
Flags: needinfo?(anygregor)
Mike can take a look from the front-end side (after 1.4 blockers :)
Whiteboard: [systemsfe]
Flagging myself to circle back once my 1.4 stuff is done.
Flags: needinfo?(mhenretty)
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #0)
> As soon you have a few notifications it starts to become slower and slower.
> Looking at a profile
> (http://people.mozilla.org/~bgirard/cleopatra/
> #report=8dfa4fd85c2e9543dadbf3fdd522e955345fb9fb) it seems like we are
> spending our time into CSS::ProcessRestyle.

I'm hoping that bug 931668 will help with this sort of profile.

> The notifications are contained basically in a div with overflow-y: scroll.
> Each time the finger is moved on the screen |div.style.transform =
> 'translateY(' + y + 'px)| is updated. The idea is to have the utility tray
> following the finger.
> 
> Asking dbaron is there any 'magic' way of avoiding the CSS::ProcessRestyle
> in this case.

I think roc had some ideas about eventually getting into a world where we could hook this sort of thing up in the layer system, but I think that was pretty long-term.  I'm not sure whether there's been any progress in that direction, though.
Flags: needinfo?(dbaron) → needinfo?(roc)
Could the utility tray itself be in a scrolling container, so that when you drag the tray with your finger you're actually scrolling the tray's container? This would let APZC do the work. The container would of course be completely transparent and contain nothing but the utility tray plus a spacing DIV to ensure that the container can be scrolled as far as necessary?
Flags: needinfo?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9)
> Could the utility tray itself be in a scrolling container, so that when you
> drag the tray with your finger you're actually scrolling the tray's
> container? This would let APZC do the work. The container would of course be
> completely transparent and contain nothing but the utility tray plus a
> spacing DIV to ensure that the container can be scrolled as far as necessary?

That sounds a good idea. But I guess we need to wait for bug 950934 to be fixed first as the utility tray lived in the parent process.
I don't think we'd block the 1.4 release, but we can certainly consider this a priority quality improvement.
blocking-b2g: 1.4? → backlog
Whiteboard: [systemsfe] → [systemsfe][priority]
Whiteboard: [systemsfe][priority] → [systemsfe], [priority]
I would be good if the platform fix for bug 931668 will prevent us to have to do any changes here.
Depends on: 931668
Comment on attachment 8384355 [details] [diff] [review]
poc.bug978588.patch

Not sure how I can help on this.
Attachment #8384355 - Flags: feedback?(lissyx+mozillians)
Now that bug 931668 has been fixed, it might be time to revisit this. We recently changed the utility tray completely, but I believe we encounter the same jank when scrolling a lot of notifications. Vivien, do you think it's worth revisiting this?
Flags: needinfo?(mhenretty) → needinfo?(21)
Priority: -- → P2
See Also: → 1073807
blocking-b2g: backlog → ---
Bug 1178162 totally fixed this.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(21)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: