Closed
Bug 967335
Opened 10 years ago
Closed 10 years ago
[Contacts][APZC] Lots of work done even after display stabilizes
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: vlad, Assigned: kats)
References
Details
(Keywords: perf, Whiteboard: [c= p= s=2014.02.28 u=] [ETA: unable to repro] )
STR: 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?
Comment 1•10 years ago
|
||
This show up in the performance profile. I see a lot of these firing but no resulting frames.
Updated•10 years ago
|
Assignee: nobody → bugmail.mozilla
Comment 2•10 years ago
|
||
This is currently blocking checkerboarding 1.3 bug.
blocking-b2g: --- → 1.3+
Updated•10 years ago
|
Whiteboard: [ETA: active triage]
Assignee | ||
Comment 3•10 years ago
|
||
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.
Assignee | ||
Comment 4•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Whiteboard: [ETA: active triage] → [ETA: unable to repro]
Updated•10 years ago
|
blocking-b2g: 1.3+ → ---
Comment 5•10 years ago
|
||
Vlad, 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. Thanks, Mike
Priority: -- → P2
Whiteboard: [ETA: unable to repro] → [c= p= s= u=] [ETA: unable to repro]
Updated•10 years ago
|
Assignee: nobody → bugmail.mozilla
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Updated•10 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.
Description
•