The bazillion image-re-uploads in issue 1110950 is one of the contributing factors (hopefully fix will land today).

Great. Thanks for the update, ccameron@. 

I think that issue number got garbled a bit.  What's the correct number?

> I think that issue number got garbled a bit.  What's the correct number?

Looks like 1110950 is the CL Number:

CL: https://chromium-review.googlesource.com/c/chromium/src/+/1110950

Bug:  Issue 851282 

Thanks, that's the one. We still (1) may have excessive layouts and (2) have a longer drawing pipeline. But part of the problem will be better.

ccameron@: Great, thank you very much. I suppose that the opening animation of the tabs will also be better then, right?

Enclosed two screencasts: MacViews vs Cocoa

Thanks.

Deleted: MacViews_Chrome.mov 1.1 MB

	MacViews_Chrome.mov 1.1 MB View Download

Deleted: Cocoa_Chrome.mov 905 KB

	Cocoa_Chrome.mov 905 KB View Download

It'll probably be better, but there's still a jerk when new tabs are open, and I'm not sure where that comes from.

> It'll probably be better, but there's still a jerk when new tabs are open, and I'm not sure where that comes from.

Thanks for your feedback. Just let me know if you want to track this separately and I should open an own report for it.

Assigning to lgrey@ for layout analysis.

I'm not seeing much in the way of layout just hovering the mouse, but we appear to be painting everything from BrowserRootView down every single frame. I tried to trace this as far as I could the other day, and it basically came down to the dirty rect being the entire thing every time.

Re #7: Opening has been bothering me too -- I think the problem there is that we're waiting for the renderer to have a frame ready before drawing (which has a huge jank).

I've attached a video of a 0 frame deadline and an 8 frame deadline.

We do want to jank the UI when we're resizing (we want it to resize with the content), so I'll see if I can be careful about that.

Deleted: deadline-0.mov 573 KB

	deadline-0.mov 573 KB View Download

Deleted: deadline-8.mov 343 KB

	deadline-8.mov 343 KB View Download

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

commit 77c834543d85b864c678d55e8cf6e4212d5bab38
Author: Christopher Cameron <ccameron@chromium.org>
Date: Sat Jun 30 18:46:22 2018

MacViews: Don't wait for frames on new tabs

Only have a non-zero deadline when resizing -- otherwise new tab
creation and tab-switch can feel janky.

Bug:  855364 
Change-Id: If198085e418f0bf9ed5af47833d23df0c37c47c7
Reviewed-on: https://chromium-review.googlesource.com/1121630
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571781}
[modify] https://crrev.com/77c834543d85b864c678d55e8cf6e4212d5bab38/content/browser/renderer_host/browser_compositor_view_mac.h
[modify] https://crrev.com/77c834543d85b864c678d55e8cf6e4212d5bab38/content/browser/renderer_host/browser_compositor_view_mac.mm

ccameron@: The New Tab Creation in mass with pressing & holding CMD-T has been improved now a lot with your patch from c#13 in Latest Canary Version 69.0.3478.0. Thank you very much!

I noticed that press & hold CMD-W (tab closing in mass) has also been improved, but it is not fast as the tab creation in mass. It seems that the lag happens, because the tab closing is waiting until the NewTabPage is rendered completely in the background. Not sure if you can improve this too?

Attached a screencast.

Deleted: CMD-T_vs_CMD-W.mov 1.2 MB

	CMD-T_vs_CMD-W.mov 1.2 MB View Download

@14: FWIW, on Windows at least we prevent auto-repeat of certain shortcuts, and ctrl-t and ctrl-w are some of them.  This makes me sad when I'm intentionally trying to test them, but OTOH if Mac also did that for parity it would prevent the issue you're talking about :)

macviews triage: is this one fixed by the HarfBuzz text caching?

No, it still paints everything. We're planning on seeing what happens if we give the tabs layers.

We did some investigation - it appears that this is vastly slower (like >100x) in the refresh tab strip vs the old tab strip. The only real difference, as far as we can tell, is the tab paths that are used:

  gfx::Path GetInteriorPath(float scale,
                            const gfx::Rect& bounds,
                            const gfx::InsetsF& insets = gfx::InsetsF()) {
    if (MD::IsRefreshUi())
      return GetRefreshInteriorPath(scale, bounds, insets);

  ...

The refresh path uses generalized arcs while the old path uses cubics. I have no idea if that is significant.

Oop, I profiled incorrectly. I will try to get more accurate profile data...

Okay, we see lower CPU use (but not none) with pre-refresh GM2 - it's more like 5x slower, not 100x. We still don't quite understand why but it probably has to do with the tab glow repainting tabs all the time.

If your profiling shows path intersection as a true hotspot, it'd be pretty easy to optimize that to occur much less, or not at all.  I'm not going to spend time on that unless it's actually a problem, but just know that that specific piece could be made to disappear if necessary.

This got a lot better with the HarfBuzz caching improvements ccameron@ landed. This is no longer Pri-1 I think but there is still work to do.

*** UI Mass Triage***

Seems like WIP and bug is valid, hence tagging with appropriate label.

We should either mark this as Available (for further future research) or close it ... marking as Fixed for now.

Of note is that HarfBuzz has a big performance fix which should be landing soon (if it hasn't already), which should help the cases which weren't fixed by the cache.