Trent: Is this something expected (the fact that the macViews would be slower than the native cocoa implementation)?

It is not expected. The problem goes away if the profile is signed in. I think it's related to some threads I'm pulling in Issue 788597.

Specifically, for the profile menu, I think it's the "Sign in to get your bookmarks..." promo text. It needs to wrap onto multiple lines, but profile_chooser_view.cc doesn't tell the views::Label how wide it needs to be. That means the first layout pass tries to put all the text on a single line and the layout system suggests that the initial size of the widget should be really wide. But then when the Widget size is actually set, and another layout pass is triggered.

So the biggest performance improvement is just from flipping chrome://flags/#enable-harfbuzz-rendertext to Enabled (but see blockers on  Issue 454835  for why this isn't done).

But I've been doing lots of work on Harfbuzz. It's currently used for textfields in toolkit-views. It's probably ready to be deployed more widely. Like, to all views::Labels as well.

I have some other simple tweaks that give a boost in https://chromium-review.googlesource.com/799614

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/616c8345fbe447467905b69cee8e4cbde8d29ffa

commit 616c8345fbe447467905b69cee8e4cbde8d29ffa
Author: Trent Apted <tapted@chromium.org>
Date: Thu Nov 30 09:58:03 2017

Partial fix for ProfileChooserView layout performance.

Currently, a Layout is triggered before adding to a Widget. This is
unnecessary since a full layout is done when adding to the Widget
(which may also invalidate any prior layout as well).

Also, when already in a Widget, there's no point doing a Layout()
before SizeToContents() since a size change is also guaranteed to
invalidate the layout.

Finally, provide a hint to the layout manager for the promo text width.
The profile switcher has a fairly complex, nested LayoutManager setup,
which is requiring a second layout pass. This can be avoided by giving
the promo text a width.

Bug:  789118 
Change-Id: I01b3e377afdaa0e948b1c6c72d008d6fd901145d
Reviewed-on: https://chromium-review.googlesource.com/799614
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520496}
[modify] https://crrev.com/616c8345fbe447467905b69cee8e4cbde8d29ffa/chrome/browser/ui/views/profiles/profile_chooser_view.cc

Tested the issue on Mac OS 10.12.6 using chrome M64 #64.0.3279.0 (reported version) and fixed build M64 #64.0.3282.0 and observed similar behavior.

Attached screencast for reference.

@msarda-- Could you please check attached screencast and confirm us about the fix and please let us know if we had missed any steps in reproducing the issue.

Thanks!

Deleted: 789118.mp4 1.1 MB

	789118.mp4 1.1 MB View Download

Deleted: 789118_latest.mp4 877 KB

	789118_latest.mp4 877 KB View Download

Eli: We do not have a clear quick solution to solve the slowness of presenting the user menu on MacViews. I'll also do a pass over this.

Should this bug block the release of profile chooser view on MacViews (should it be an RBS for M64)?

I think r520496 alone makes this pretty good, and I don't think it's worth blocking m64.

In m65 there is r522617 which improves it further, but that is not mergeable.

Further improvements are coming with WIP fixes for  Issue 785522  (http://crrev.com/c/823743) and Issue 788597 (http://crrev.com/c/790175).

Based on comment #8, I'm removing the RBS label and marking this bug blocked on the  Issue 785522  and Issue 788597 .

Trent: I am assigning this bug to you as it looks like you are the one doing the work (and thus should also get the credit for it being fixed). Please re-assign to me if you think I need to fix anything that is specific to the profile_chooser_view.

I'm gonna close this out.

 Issue 785522  is basically fixed -- it's just open for landing some performance regression tests. Early indications are that Mac is still slower than other platforms on that particular perf test (which is one small part of the overall perf relating to this Issue): about one-third of Windows and one-fifth of Linux. This could be due to different hardware we have available for testing on Mac, which tends to be updated a lot less often. It could also be due to complexity of glyphs in the system font on Mac.

Issue 788597 affects all platforms, and there are mitigations in place for the profile switcher already.

I can't perceive any latency on Mac any more (retina or non-retina, signed in or signed out, Cmd+Shift+m or clicking).