Closed Bug 69101 Opened 24 years ago Closed 24 years ago

Things that slow down mac painting

Categories

(Core :: Layout, defect)

PowerPC
Mac System 9.x
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

Details

(Keywords: topperf)

Attachments

(1 file)

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.
Keywords: nsmac1, patch, topperf
Target Milestone: --- → mozilla0.9
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.  
sr=sfraser
both patches checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: