- 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.
nsbeta3+, P5 for M18.
Priority: P3 → P5
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?
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.
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.
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, &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?
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.
Target Milestone: M18 → Future
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...
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. ugh!
waiting on many of the dependency bugs to be fixed...
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla1.0
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
Whiteboard: wanted for 0.9.1/Mojo beta → wanted for 0.9.1/Mojo beta [nav+perf]
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
Status: ASSIGNED → NEW
I'm futuring this bug because I'm not going to get to it before mozilla-1.0.
Target Milestone: mozilla0.9.7 → Future
I'll take this
Assignee: waterson → sfraser
Status: ASSIGNED → NEW
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 :-)
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.