Closed
Bug 583038
Opened 15 years ago
Closed 15 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•15 years ago
|
blocking2.0: --- → ?
Comment 1•15 years ago
|
||
What's the stack to that? Invalidation, or something else?
| Reporter | ||
Comment 2•15 years ago
|
||
nsDisplayList::ComputeVisibilty called by nsLayoutUtils::PaintFrame()
Comment 3•15 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•15 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•15 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: 15 years ago
Resolution: --- → DUPLICATE
blocking2.0: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•