870404 - nsCocoaWindow::SetSizeConstraints is heavy weight

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

I see this showing up in a bunch of profiles:

http://people.mozilla.org/~bgirard/cleopatra/#report=5e99c91c8280076e51641fe874a47cabd128eb97&search=SyncWindow
http://people.mozilla.org/~bgirard/cleopatra/#report=36d1f92b1c7673b67f214c8c4777bdb174e7ba21

Comment 1

[Steven Michaud [:smichaud] (Retired)]

All the "weight" seems to come from the following line, which triggers a reflow:

http://hg.mozilla.org/mozilla-central/annotate/ea059733677c/widget/cocoa/nsCocoaWindow.mm#l1140

So if this is a problem, it's presumably a problem in cross-platform code.

Do we have comparable results for other platforms?

Comment 2

[Steven Michaud [:smichaud] (Retired)]

By the way, to see SetSizeContraints() at all you'd (presumably) need to be resizing your browser window during the test.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Actually, in both of your examples the window is being resized during a transition to or from fullscreen mode.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

There should be no resizing during either of these profiles. It's not clear to me why _NSWindowFullScreenTransition is on the stack. Anyways here's a representative stack:

mach_msg_trap
_CGSGetWorkspace
+[_NSWindowFullScreenTransition _fullScreenInstanceInWorkspace:]
_NXLayoutRectForScreen
_NXVisibleRectForScreen
-[NSScreen visibleFrame]
-[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:]
-[NSWindow(NSWindowResizing) _getEdgeResizingRects:]
-[NSWindow(NSWindowResizing) _updateEdgeResizingTrackingAreas]
-[NSWindow(NSWindowResizing) _noteAllowedResizeDirectionsMayHaveChanged]
nsCocoaWindow::SetSizeConstraints(mozilla::widget::SizeConstraints const&)
nsContainerFrame::SetSizeConstraints(nsPresContext*, nsIWidget*, nsSize const&, nsSize const&)
nsContainerFrame::SyncWindowProperties(nsPresContext*, nsIFrame*, nsView*, nsRenderingContext*)
PresShell::DoReflow(nsIFrame*, bool)
layout::DoReflow (chrome://browser/content/browser.xul)
PresShell::ProcessReflowCommands(bool)
PresShell::FlushPendingNotifications(mozilla::ChangesToFlush)
layout::Flush (Flush_Layout)
nsDocument::FlushPendingNotifications(mozFlushType)
mozilla::dom::Element::GetBoundingClientRect()

The actual expensive time is being spent in CGSGetWorkspace called by -[NSWindow(NSWindowResizing) _noteAllowedResizeDirectionsMayHaveChanged] which is presumably doing synchronous ipc to the window server.

It looks like we call SyncWindowProperties everytime we do a reflow of content/browser.xul. Maybe layout should avoid calling SyncWindowProperties if things have not changed.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> It's not clear to me why _NSWindowFullScreenTransition is on the stack.

That's because the browser window is in the midst of an animated transition to or from fullscreen mode.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> The actual expensive time is being spent in CGSGetWorkspace called
> by -[NSWindow(NSWindowResizing)
> _noteAllowedResizeDirectionsMayHaveChanged] which is presumably
> doing synchronous ipc to the window server.

That's not how I read these profiles.  In fact CGSGetWorkspace seems
to take no time at all on its own.  Almost all of its time is spent in
its call (indirectly) to nsContainerFrame::SyncWindowProperties(),
because that triggers a reflow.

By the way, I click "Invert callstack" before I look at these
profiles.

What do you think, Benoit?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I'm not sure I'm reading the profiles correctly, but I *am* sure they were taken while the browser window was in a fullscreen mode transition.

One way to test is to do the following:

Take two different profiles.

For one of them do nothing at all for the life of the profile.

For the other keep turning fullscreen mode off and on for the life of the profile.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #7)

I did these tests, and I didn't get what I expected.

So I now have frankly no idea what the situation is with nsCocoaWindow::SetSizeConstraints().

Is there any way to search through a profile for any "mention" of a method without filtering?  That might give a better idea of how "heavy" any given method is (or the methods called from it) relative to everything else that's going on.

As best I can tell, if you filter you rebase the profiler's statistics to every callstack that includes what you're filtering for -- the total is always by definition 100%.  So if you filter you lose your ability to compare with other callstacks that *don't* include what you're filtering for.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Another thing that'd be very useful is an "expand all" capability.  If there is one, I can't find it.