[Contacts][APZC] Lots of work done even after display stabilizes




5 years ago
5 years ago


(Reporter: vlad, Assigned: kats)



Gonk (Firefox OS)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [c= p= s=2014.02.28 u=] [ETA: unable to repro] )

1. Open up contacts app with medium workload loaded.
2. Move to somewhere mid-list.
3. Set breakpoints in contacts app in a few places.. nsHTMLScrollFrame::BuildDisplayList is a good one, same with nsRefreshDriver::ScheduleViewManagerFlush
4. Disable all breakpoints
5. Scroll a tiny bit in direction of previous scroll
6. When display visually stabilizes, hit Control-C in debugger
7. Enable all your breakpoints

At this point we're going to do a bunch of paints and other bits for a long while after scrolling has already fully visually stopped.

Also related: a breakpoint in nsGfxScrollFrame.h:454-ish (nsHTMLScrollFrame::BuildDisplayList) triggers a ton during this after-visual-stop period.  100+ times easily, with very deep stacks (20-deep calls to nsIFrame::BuildDisplayListForChild with other BuildDisplayList* calls interspersed).  Many of the RefreshDriver::ScheduleViewManagerFlush calls that lead to painting in the above are coming from mozilla::widget::APZCCallbackHelper::UpdateSubFrame.

Some of these display list builds are also coming from PresShell::UpdateImageVisibility; are we maybe decoding images that are in/near our very large viewport, thus scheduling lots of decides this way too?
Keywords: perf
This show up in the performance profile. I see a lot of these firing but no resulting frames.
Assignee: nobody → bugmail.mozilla
This is currently blocking checkerboarding 1.3 bug.
blocking-b2g: --- → 1.3+
Whiteboard: [ETA: active triage]
So I've seen stuff like this before, but am not able to reproduce it now. I tried on 1.3 with hamachi and master with the Peak, scrolling around on the contacts app and waiting till it stabilizes. Rather than use breakpoints I just added printfs to some places that run when we do a repaint. I see the printfs fire during scrolling, and then there's a flurry of them after right after stabilization for about 0.5 seconds (from past investigations I believe this to be the scrollbar fade-out) and then maybe one or two more a few seconds later. Some of these might be removable but I'm not sure how much work they're actually doing or if they're no-op paints, so I don't know if it's worth the effort right now.
Still unable to reproduce this. Unassigning from myself for now; if there are different STR I can try again. Or if somebody else can repro they can take it.

Vlad, in comment 0 you say that UpdateSubFrame is the source of some of the calls. That is triggered by the APZC, but to find out which why that's happening we would need to stick a breakpoint at [1] (in the root process) and see who's calling that.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp?rev=66cba27e5910#1364
Assignee: bugmail.mozilla → nobody
Whiteboard: [ETA: active triage] → [ETA: unable to repro]
blocking-b2g: 1.3+ → ---

Comment 5

5 years ago

Based on comment 3 and comment 4 this may not need to block bug 967277. Please retry with Kats' comment 4 suggestion then update this bug saying whether it's still an issue and if it should continue to block bug 967277.

Priority: -- → P2
Whiteboard: [ETA: unable to repro] → [c= p= s= u=] [ETA: unable to repro]
Assignee: nobody → bugmail.mozilla
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME


5 years ago
Whiteboard: [c= p= s= u=] [ETA: unable to repro] → [c= p= s=2014.02.28 u=] [ETA: unable to repro]
You need to log in before you can comment on or make changes to this bug.