48274 - Window refresh is slow

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P2)

Description

[Mike Pinkerton (not reading bugmail)]

- 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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

marking with the necessary bits

Comment 2

[Peter Trudelle]

nsbeta3+, P5 for M18.

Comment 3

[Mike Pinkerton (not reading bugmail)]

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.

Comment 4

[Mike Pinkerton (not reading bugmail)]

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

[Simon Fraser [no longer active]]

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.

Comment 6

[Mike Pinkerton (not reading bugmail)]

cc'ing don and kevin

There are two places where we spend the bulk of the time handling the update 
event:
- 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/
bottom):

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 7

[Mike Pinkerton (not reading bugmail)]

Attachment: Timeline of fillrect/blitting compared to update time

Comment 8

[Simon Fraser [no longer active]]

Marking dependent on the view opacity bug 34887.

Comment 9

[Mike Pinkerton (not reading bugmail)]

Attachment: another picture of the overpainting timeline

Comment 10

[Mike Pinkerton (not reading bugmail)]

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.

Comment 11

[Mike Pinkerton (not reading bugmail)]

just profiled the nsRenderingContextMac::CopyOffScreenBits() call and it's 
entirely the CopyBits() toolbox call.

any tricks that we can do to speed up copybits?

Comment 12

[Simon Fraser [no longer active]]

http://www.mactech.com/articles/develop/issue_18/043-054_Othmer_REV.html
http://developer.apple.com/technotes/qd/qd_21.html

Comment 13

[Mike Pinkerton (not reading bugmail)]

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, &qd.black); 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.

anyone?

Comment 14

[Peter Trudelle]

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.

Comment 15

[Peter Trudelle]

nsbeta3-

Comment 16

[Mike Pinkerton (not reading bugmail)]

I've noticed that in modern these days, windows refresh in bands. something
about modern seems to really trick out our repaint code...

Comment 17

[Mike Pinkerton (not reading bugmail)]

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.

ugh!

Comment 18

[Mike Pinkerton (not reading bugmail)]

waiting on many of the dependency bugs to be fixed...

Comment 19

[Peter Trudelle]

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.

Comment 20

[Cathleen]

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?

Comment 21

[Mike Pinkerton (not reading bugmail)]

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?

Comment 22

[Mike Pinkerton (not reading bugmail)]

giving back to the perf team. my shorterm plate is full of more pressing matters.

Comment 23

[Chris Waterson]

I'm futuring this bug because I'm not going to get to it before mozilla-1.0.

Comment 24

[Simon Fraser [no longer active]]

I'll take this

Comment 25

[Henrik Lynggaard Hansen]

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

[Simon Fraser [no longer active]]

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.