Chrome Version       : 56.0.2914.3
OS Version: OS X 10.12.1

What steps will reproduce the problem?
1. With MacViews, open the Task Manager, resize it a bunch

What is the expected result?

Smooth resize

What happens instead of that?

Even on a high performance machine, ui::WindowResizeHelperMac sometimes fails to receive a frame within 50ms and redraws the window frame without an updated window contents, resulting in black gumf around the window edge. (we put up with this on Windows and Linux, but we're fussier on Mac).

Both RenderTextMac and RenderTextHarfbuzz seem to have similar CPU usage, but I think there's some low-hanging fruit in RenderTextHarfbuzz that could put it on top. (e.g. calls to gfx::Font::Derive that could be cached)

At a glance, I think there's some low-hanging fruit in the shared parts too. E.g. there are multiple calls to EnsureLayout under DrawStringRectWithFlags -- one for drawing, one for eliding. There might be a way to layout only once and effectively double performance.

Attaching symbolized two traces: one with --enable-harfbuzz-rendertext and one without, for the "resize task manager a bunch" test case, over 3000ms.

Note there's some noise in the delay between me hitting "sample" and starting to resizing the window. Noteworthy bits:

- gfx::Canvas::DrawStringRectWithFlags: 158ms harfbuzz, 184ms mac
- DrawStringRectWithFlags calling EnsureLayout multipe times: once for elide, once for draw
- Also a layout called via gfx::Canvas::GetStringWidth
 - which is also called via views::CalculateTableColumnSizes
- A surprising (to me) sample taken inside FontListImpl::GetFonts(): It has a CHECK(FontList::ParseDescription(..)) which might be expensive in release code.
- noticable std::vector<gfx::BreakList> memory management in gfx::internal::StyleIterator::StyleIterator
- ui::FormatBytes isn't cheap (4% of drawing time)

Latency
 - base::WaitableEvent::Wait in content::BrowserGpuMemoryBufferManager::AllocateGpuMemoryBufferForSurface
 - IPC::SyncChannel::WaitForReply in gpu::GpuChannelHost::ValidateFlushIDReachedServer

The Window resize
 - ScreenMac::GetDisplayNearestWindow is slow (called by WidgetDelegate::SaveWindowPlacement, AND by BridgedNativeWidget::UpdateLayerProperties(), when under BridgedNativeWidget::OnSizeChanged()) (the slow bit is mostly under -[NSWindow _bestScreenBySpaceAssignmentOrGeometry]). Also called internally by AppKit under -[_NSViewLayerSurface update] (under [NSThemeFrame setFrameSize:], and under -[NSView _invalidateFocus] of BridgedContentView).
 - and under -[NSWindow showsFullScreenButton]!!

**  - AND called under gfx::ApplyNSWindowSizeConstraints(..) - this is triggered by views::View::BoundsChanged(..) calling views::BridgedNativeWidget::OnSizeConstraintsChanged() -- maybe that can be avoided entirely. For a 100ms saving.
  - wow - I have an easy fix for this already - https://codereview.chromium.org/2502813003/

Other stuff
 - -[AppMenuButtonViewController containerSuperviewFrameChanged:] gets a notification posted when the window resizes -- why? (probably not filtering its subscription properly).


Everything, ranked.

-[NSWindow _bestScreenBySpaceAssignmentOrGeometry]
        27       -[NSCGSWindow(NSCGSSpace) bestSpaceContainingWindow]  (in AppKit) + 39  [0x7fff81cf72f4]
        27       -[NSWindow _bestScreenByGeometryOfFrame:respectingSpaceAssignment:]  (in AppKit) + 654  [0x7fff81727934]
        27       -[NSWindow _bestScreenBySpaceAssignmentOrGeometry]  (in AppKit) + 71  [0x7fff8172769d]
        24       NSCGSWindowBestManagedDisplayMatchesByGeometry  (in AppKit) + 231  [0x7fff8189f737]
        23       -[NSCGSWindow(NSCGSSpace) bestSpaceContainingWindow]  (in AppKit) + 63  [0x7fff81cf730c]
        23       SLSCopyBestManagedDisplayForRect  (in SkyLight) + 327  [0x7fff94f2ec45]
        22       SLSCopySpacesForWindows  (in SkyLight) + 199  [0x7fff94f2bfe5]
        22       _NSCGSWindowGetSpaceIDs  (in AppKit) + 115  [0x7fff81cf72a6]
        21       NSCGSWindowBestManagedDisplayMatchesByGeometry  (in AppKit) + 261  [0x7fff8189f755]
        21       __SLSCopySpacesForWindows_block_invoke  (in SkyLight) + 175  [0x7fff94f2c0bc]
        19       SLSCopyManagedDisplayForWindow  (in SkyLight) + 170  [0x7fff94f2ed63]

-[NSWindow showsFullScreenButton]
        14       -[NSWindow _implicitlyAllowsFullScreenPrimary]  (in AppKit) + 233  [0x7fff81733242]
        7       -[NSWindow _effectiveCollectionBehavior]  (in AppKit) + 50  [0x7fff81732dbe]
        7       -[NSWindow _implicitlyAllowsFullScreenPrimary]  (in AppKit) + 322  [0x7fff8173329b]

gfx::Font::Derive
        17       -[NSFontManager traitsOfFont:]  (in AppKit) + 37  [0x7fff818b3183]
        16       -[NSCTFontDescriptor objectForKey:]  (in UIFoundation) + 21  [0x7fff961656cb]
        16       -[NSFontDescriptor symbolicTraits]  (in UIFoundation) + 33  [0x7fff96164e7a]
        16       CTFontDescriptorCopyAttribute  (in CoreText) + 98  [0x7fff8500e8bb]
        11       TDescriptor::CopyAttribute(__CFString const*) const  (in CoreText) + 204  [0x7fff8500e9c4]
        9       -[NSFontManager convertFont:toHaveTrait:]  (in AppKit) + 92  [0x7fff819ac89b]
        9       -[NSFontManager convertFont:toNotHaveTrait:]  (in AppKit) + 36  [0x7fff819ac763]
        9       gfx::Font::Derive(int, int, gfx::Font::Weight) const  (in Google Chrome Framework)  load address 0x103188000 + 0x1dcd3d1  [font.cc:45]
        9       gfx::internal::CreateSkiaTypeface(gfx::Font const&, bool, gfx::Font::Weight)  (in Google Chrome Framework)  load address 0x103188000 + 0x1dea414  [render_text_mac.mm:76]
        9       TComponentFont::CopyAttribute(unsigned long) const  (in CoreText) + 88  [0x7fff8500f890]
        9       TTenuousComponentFont::CopyAttribute(unsigned long) const  (in CoreText) + 61  [0x7fff850ec161]
        8       -[NSFontManager convertFont:toHaveTrait:]  (in AppKit) + 121  [0x7fff819ac8b8]
        7       gfx::PlatformFontMac::PlatformFontMac(NSFont*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int, int, gfx::Font::Weight)  (in Google Chrome Framework)  load address 0x103188000 + 0x1dd7ba6  [platform_font_mac.mm:192]
        7       gfx::PlatformFontMac::DeriveFont(int, int, gfx::Font::Weight) const  (in Google Chrome Framework)  load address 0x103188000 + 0x1dd7cda  [platform_font_mac.mm:190]
        7       TBaseFont::CopyAttribute(unsigned long) const  (in CoreText) + 336  [0x7fff8500fa02]
        7       TDescriptor::CopyAttribute(__CFString const*) const  (in CoreText) + 30  [0x7fff8500e916]
        6       gfx::PlatformFontMac::DeriveFont(int, int, gfx::Font::Weight) const  (in Google Chrome Framework)  load address 0x103188000 + 0x1dd7c71  [platform_font_mac.mm:112]
        6       TBaseFont::CopyTraits(bool) const  (in CoreText) + 35  [0x7fff850e5c0b]
        6       TBaseFont::CopyTraitsInternal() const  (in CoreText) + 43  [0x7fff85029733]
        5       gfx::PlatformFontMac::DeriveFont(int, int, gfx::Font::Weight) const  (in Google Chrome Framework)  load address 0x103188000 + 0x1dd7c92  [platform_font_mac.mm:114]
        5       gfx::PlatformFontMac::DeriveFont(int, int, gfx::Font::Weight) const  (in Google Chrome Framework)  load address 0x103188000 + 0x1dd7cac  [platform_font_mac.mm:117]

RenderText layout (HarfBuzz)
        10       gfx::RenderTextHarfBuzz::EnsureLayoutRunList()  (in Google Chrome Framework)  load address 0x103188000 + 0x1de421e  [iterator:1311]
        10       gfx::RenderTextHarfBuzz::ShapeRunWithFont(std::__1::basic_string<unsigned short, base::string16_char_traits, std::__1::allocator<unsigned short> > const&, gfx::Font const&, gfx::FontRenderParams const&, gfx::internal::TextRunHarfBuzz*)  (in Google Chrome Framework)  load address 0x103188000 + 0x1de77c6  [SkRefCnt.h:308]
        10       gfx::RenderTextHarfBuzz::ShapeRun(std::__1::basic_string<unsigned short, base::string16_char_traits, std::__1::allocator<unsigned short> > const&, gfx::internal::TextRunHarfBuzz*)  (in Google Chrome Framework)  load address 0x103188000 + 0x1de7d64  [render_text_harfbuzz.cc:1350]
        9       gfx::RenderTextHarfBuzz::EnsureLayoutRunList()  (in Google Chrome Framework)  load address 0x103188000 + 0x1de41bd  [render_text_harfbuzz.cc:1569]


toolkit-views framework stuff [actually this is calling NSWindow schedulePaintInRect, which takes up more of the time]
        9       views::View::SchedulePaintInRect(gfx::Rect const&)  (in Google Chrome Framework)  load address 0x103188000 + 0x30f0084  [view.cc:760]


The rest are probably hard to improve on: moved into more_things_ranked.txt
 

Deleted: TRIMMED_harfbuzz_draw_string_rect.txt 119 KB

TRIMMED_harfbuzz_draw_string_rect.txt 119 KB View Download

Deleted: harfbuzz_draw_string_rect.txt 1.1 MB

harfbuzz_draw_string_rect.txt 1.1 MB View Download

Deleted: render_text_mac_draw_string_rect.txt 1.1 MB

render_text_mac_draw_string_rect.txt 1.1 MB View Download

Deleted: more_things_ranked.txt 13.3 KB

more_things_ranked.txt 13.3 KB View Download