We are spending 10% of the time in nsIFrame::GetOffsetToCrossDoc() and overall it seems like we're doing more than we should be.
What's the stack to that? Invalidation, or something else?
nsDisplayList::ComputeVisibilty called by nsLayoutUtils::PaintFrame()
There is an existing bug for scrolling on gmail being slow as a regression from retained layers, that's bug 579260. Jeff, would you be willing to reprofile if I gave you a patch to try?
(In reply to comment #3) > There is an existing bug for scrolling on gmail being slow as a regression from > retained layers, that's bug 579260. > > Jeff, would you be willing to reprofile if I gave you a patch to try? Yes, but I won't probably won't get a chance till Monday
Created attachment 461315 [details] [diff] [review] patch to try This undo's some changes that were made in bug 563878. I'm interested in how this affects the GetOffsetToCrossDoc time.
I believe the problem in gmail scrolling is that we're painting much too much, not that any one function is slow.
Depends on: 579260
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 579260
blocking2.0: ? → ---
You need to log in before you can comment on or make changes to this bug.