Closed
Bug 69101
Opened 24 years ago
Closed 24 years ago
Things that slow down mac painting
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: mikepinkerton, Assigned: mikepinkerton)
Details
(Keywords: topperf)
Attachments
(1 file)
1.73 KB,
patch
|
Details | Diff | Splinter Review |
Two things i found that slowed down painting on mac: The first was, for multi monitor systems, we were taking about 8% of the time to calculate which screen the device content was on. All of this time, however, was taken up by subtracting out the height of the titlebar from the window rect. Why we were doing this, I don't know, but since it's only an approximation anyway, it really doesn't matter if we do or don't include the title bar. Removing the title bar code dropped GetScreenForSurface() off the radar. Second, there are 2 places in nsCSSRenderer where we use paths to approximate rounded borders (nsCSSPaintRoundedBorder and nsCSSPaintRoundedBackground). Each routine has a stack-based array of 1000 nsPoints (!!!). Initializing this array took 18% (!) of the all paint time, and over 65% of the time in these routines. Making these two arrays static dropped these routines more or less of the radar. I already have r=saari, dcone do you object to the static's in the CSS rendering code (it's your code)? patch for both forthcoming.
Assignee | ||
Comment 1•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Comment 2•24 years ago
|
||
For that particular code.. Peter L(long gone) was suppose to give me a data structure to use for those points that was faster and lighter.. but when he left I totally forgot about that. good find! r=dcone.
Comment 3•24 years ago
|
||
sr=sfraser
Assignee | ||
Comment 4•24 years ago
|
||
both patches checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•