Closed
Bug 583038
Opened 14 years ago
Closed 14 years ago
Scrolling gmail is slow on OS X
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 579260
People
(Reporter: jrmuizel, Unassigned)
References
Details
Attachments
(1 file)
3.05 KB,
patch
|
Details | Diff | Splinter Review |
We are spending 10% of the time in nsIFrame::GetOffsetToCrossDoc() and overall it seems like we're doing more than we should be.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
What's the stack to that? Invalidation, or something else?
Reporter | ||
Comment 2•14 years ago
|
||
nsDisplayList::ComputeVisibilty called by nsLayoutUtils::PaintFrame()
Comment 3•14 years ago
|
||
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?
Reporter | ||
Comment 4•14 years ago
|
||
(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
Comment 5•14 years ago
|
||
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
Closed: 14 years ago
Resolution: --- → DUPLICATE
blocking2.0: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•