19 years ago
5 years ago


(Reporter: mikepinkerton, Assigned: sfraser_bugs)


(Depends on 1 bug, {helpwanted, meta, perf})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: wanted for 0.9.1/Mojo beta [nav+perf])


(2 attachments)

- launch mozilla
- cover it with a few finder windows
- switch back to mozilla

expected results:
- window draws immediately, too fast for the eye to see

actual results:
- you see large white patches while the window refreshes, obviously slower 
refresh than every other mac application on the same machine (G4, 450).

Filing the bug in hopes of being allowed to work on it, cc'ing smart mac folks.
marking with the necessary bits
Keywords: nsbeta3, perf

Comment 2

19 years ago
nsbeta3+, P5 for M18.
Priority: P3 → P5
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
I ran it through with the instrumentation sdk and the time is almost exactly 
split between processing the activate event (which sends the focus events around 
through gecko) and the update events (which does lots of painting).

Interesting things to note:

- handling the focus event causes contentInserted and contentRemoved methods to 
be called and frames to be recreated for content nodes (cssFrameConstructor is 
involved). This doesn't seem good

- since gecko doesn't quite understand regions, we end up blitting from offscreen 
a bunch of times (like > 20). Chances are good this is why repaint looks so 
flashy, because we blit one area at a time in sequence, not the entire region 
that was damaged all at once

So we have two avenues for making this better: focus and paint. cc'ing hyatt 
since XBL shows up in the profile data for handling the focus.
another thing showing up in the profile is the url bar is getting the DOM 
selection, which is a fairly expensive thing to do. It involves XIF conversion, 
which builds up and tears down a content model while it's running the parser over 
it. Ugh!

simon, is the selection used only to see if it's empty or not (for updating cut/
copy/etc)? Could an API be written that asks if the selection is empty w/out 
translating the entire selection, only to have it throw away?

Comment 5

19 years ago
A note about the number of offscreen blits (which is affected by the region to 
rect code) - 
Whether we redraw/blit just one rect or several depends on the complexity of the 
update region. If it contains >= 10 rects, we do just one redraw/blit. If < 10, 
we do a redraw/blit for each one. This is easy to see if you turn double 
buffering off, and change the complexity of the update region by layering some 
varying number of Finder windows on top of the browser window before bringing the 
browser to the front.

This region->rect code can result in the redraw/blit of several small rectangles, 
which would be better handled as a single one. I'd like to see us calculate some 
function of 'region complexity', or perhaps compare the area of the region w.r.t. 
the area of its bounding box. This would give us a better idea of whether it's 
better to do one big or several small redraws/blits.

w.r.t. getting the selection: let me know what method is the bottleneck, and I'll 
figure something out.
Blocks: 49141
cc'ing don and kevin

There are two places where we spend the bulk of the time handling the update 
- FillRect (about .13 of .17 seconds, 75%)
- CopyOffScreenBits (blitting, 0.02 of .17, 12%)

I'll attach the timeline that shows this pretty clearly. We spend a lot of time 
in FillRect painting large portions of the screen over and over and over again. 
Here are the areas we paint for refreshing the window (coords are left/top/right/

rect: 0 0 808 563
rect: 0 0 809 564
rect: 0 0 809 564
rect: 0 0 809 60
rect: 0 0 809 43
rect: 1 1 13 42
rect: 233 9 752 34
rect: 256 16 730 29
rect: 256 16 730 29
rect: 0 43 809 59
rect: 1 44 13 58
rect: 0 532 809 548
rect: 0 0 808 472
rect: 0 -60 809 504
rect: 0 -60 809 504
rect: 0 0 808 472
rect: 0 0 809 472
rect: 0 0 808 472
rect: 0 0 809 472

That's a lot for _one_ paint event. Would better handling of opaque views here 
help? Note this is with about:blank as the webpage.

Comment 8

19 years ago
Marking dependent on the view opacity bug 34887.
Depends on: 34887


19 years ago
No longer depends on: 34887


19 years ago
Depends on: 34887
the last attachment illustrates how we paint repeatedly each time we go down 
another layer into a subwidget, then at the end, blit the whole thing.
just profiled the nsRenderingContextMac::CopyOffScreenBits() call and it's 
entirely the CopyBits() toolbox call.

any tricks that we can do to speed up copybits?
I tried the hack of processing the update event as soon as the activate event 
comes in (so that we draw first before any other processing) and it still feels 
as slow as ever. Instrumentation shows that even though we are doing all the 
painting first, it still takes too long before we paint (at least 0.1 seconds 
for small areas, longer for larger ones), and so it's very noticable.

Just as a side note, I tried replacing our "send the paint event into gecko" 
with a ::FillRgn(updateRgn, &; return NS_OK; and the window refreshes 
_immediately_ with no visible signs of flashing. So the flashing that we see is 
caused directly by Gecko's inability to quickly refresh areas.

I don't think that speeding up the activate/focus processing will get us 
anything if we don't speed up the time from when the window comes to the front 
to the time the pixels are blitted to the screen.


Comment 14

19 years ago
Mass-moving P4/P5 bugs to Future milestone.  We just don't have any time left
for these, although we could still consider taking a good patch.  Adding
Helpwanted keyword.
Keywords: helpwanted
Target Milestone: M18 → Future

Comment 15

19 years ago
Whiteboard: [nsbeta3+] → [nsbeta3-]
I've noticed that in modern these days, windows refresh in bands. something
about modern seems to really trick out our repaint code...
OS: All
Target Milestone: Future → mozilla0.9
I just did some profiling this afternoon and discovered the following:

- copybits isn't really the problem i thought it was
- time is more or less equally split between the "activation" event (where 
enabled/disabled states are set and menus are updated) and the "update" event 
(where painting the damaged areas happens).

Inside the 'activation' event, about 50% of the time is spent in 
nsCSSFrameCtor::RecreateFrameForContent caused by changing attributes on menus. 
On mac, remember, menus are native and thus have no frames. CSS, however, thinks 
that frames might be needed since an attribute may cause some other style rule to 
come into effect, but alas, none does for mac menus. they're always display:none. 
So tenths of seconds later, CSS comes up empty and returns to normal.

I also noticed that XBL is involved in updating mac menus. It shouldn't be, so it 
means we're creating lots of anonymous content for no reason.

Depends on: 69010, 69142, 69143, 69414
Depends on: 70283, 70290
Depends on: 72923
waiting on many of the dependency bugs to be fixed...
Keywords: meta
Target Milestone: mozilla0.9 → mozilla0.9.1


18 years ago
Blocks: 77421
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: mozilla0.9.1 → mozilla1.0

Comment 19

18 years ago
Can we put some more pressure on owners of dependent bugs to fix this in 0.9.1?
 This is one of the worst responsiveness defects we have, and a dependency of
one of the nscatfood bugs with the most votes.  changing priority to p2.
Priority: P5 → P2
Whiteboard: wanted for 0.9.1/Mojo beta


18 years ago
Depends on: 34887


18 years ago
Whiteboard: wanted for 0.9.1/Mojo beta → wanted for 0.9.1/Mojo beta [nav+perf]

Comment 20

18 years ago
this is one of top UI responsiveness issues that users are complaining about.
switching between windows peformance is not good.

pink, can you figure out what we need to do?  are you still blocked by your
depending bugs (bug 34887, bug 69010, bug 69143)?  any other additional issues?


18 years ago
Blocks: 91351
i profiled this on osx with sampler, but since the OS keeps a window backing-
store, there's not much work going on and it's really fast. Time spent in 
setFocus and resolving style, but not a whole lot. In fact, the slowest part 
seems to be redrawing the menubar at the OS level ;)

i tried to profile this on win32, but &#@*%^ Rational won't honor the license 
agreement that phil paid for. Anyone have good Rational-fu that can help me get 
this piece of #*@%*^ installed?
Target Milestone: mozilla1.0 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
giving back to the perf team. my shorterm plate is full of more pressing matters.
Assignee: pinkerton → waterson


18 years ago


18 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6


18 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 23

18 years ago
I'm futuring this bug because I'm not going to get to it before mozilla-1.0.
Target Milestone: mozilla0.9.7 → Future

Comment 24

18 years ago
I'll take this
Assignee: waterson → sfraser
Target Milestone: Future → mozilla1.1
This bug has not been touched for more than a year. In most cases, that 
means it has "slipped through the net". Please could the owner take a moment to 
add a comment to the bug with current status, and/or close it.

Thank you :-)

Comment 26

16 years ago
We've moved on since this bug was filed, and the performance data is likely no
longer applicable. Also, since we OS X only, and OS X uses a window backing
store, it's really not relevant now.
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.