I feel like this regressed at some point.. There's a parameter

void BridgedNativeWidget::MaybeWaitForFrame(const gfx::Size& size_in_dip) {
  if (!layer()->IsDrawn() || compositor_widget_->HasFrameOfSize(size_in_dip))
    return;

  const int kPaintMsgTimeoutMS = 50;
..
  ui::WindowResizeHelperMac* resize_helper = ui::WindowResizeHelperMac::Get();
  for (base::TimeTicks now = start_time; now < timeout_time; now = base::TimeTicks::Now()) {
    if (!resize_helper->WaitForSingleTaskToRun(timeout_time - now))


Changing kPaintMsgTimeoutMS to something like 500ms makes this go away in a Chromium debug build, but that shouldn't be necessary in a release build (unless maybe if you're compiling Chrome in the background). 

The same system (and timeout) is used for making resize of the content area smooth. I'll try a bisect.

bisect didn't reveal much - the janky behaviour goes back to r351012 when we started synchronizing the resize. Maybe this is an SDK thing.

It would be super weird if the timeout isn't enough for a delta resize, but the same 50ms timeout is enough to do the entire create, layout and first paint of the window before the sheet is displayed (when it isn't, the sheet animates a grey window in when showing).

(command: ./tools/bisect-builds.py --use-local-cache -amac --good=300000 -- --secondary-ui-md --enable-mac-views-dialogs --enable-features=MacViewsNativeDialogs --user-data-dir=/Users/tapted/udd20170119 --no-first-run

So I was playing with this on http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_onbeforeunload and comparing the behaviour with Safari. Observations:
 - Resizing from the right side of the window is fine.
 - Resizing from the left side results in jankiness
(for a sheet like edit bookmarks - resizing either side sizes "both", so it always gets some janky times).

When resizing from the left, what seems to happen is this:
 - Resize starts, content gets told "make me bigger"
 - Frame comes in and gets swapped, layer updates on screen: it's now wider than the available space
 - The NSWindow catches up, moves its left edge / origin and content is now in the right place

Oddly, resizing from the *top* is fine.

Similarly, resizing the edit bookmarks view from the bottom only doesn't get janky. It's just something about updates to [window frame].origin.x that are doing something weird....

Another possibility is that the resize "overshoots" sometimes and has to send another frame to correct it.

Here's an example from MacViews browser that can be triggered by resizing from the top right (which it sounds like didn't cause jank in #3), in case it's helpful.

Deleted: macviews_nonatomic.mov 400 KB

macviews_nonatomic.mov 400 KB Download

Yah, mac_views_browser has a more complex problem since there are two compositors to keep in sync. I'm going to have to concoct an interesting solution to that. E.g. We currently block in -[NSView setFrame:] immediately after shipping the IPC to resize the compositor. Instead I want to move these further apart so more things can be parallelised.

The problem I'm describing in #c3 affects the Cocoa browser (i.e. MacViews not involved at all). But MacViews uses some of the same setup, so it is also affected.

See attached video. That jitter for e.g., the "Result Size: foo x bar" text is the bug we need to fix.

Deleted: topleft_resize_jitter.mov 3.6 MB

topleft_resize_jitter.mov 3.6 MB Download

Fixing that would be interesting. Comparing with Safari, it looks like they have a much higher tolerance for blocking the main thread, which is bad in its own way :). See attachments.

Deleted: resize_jank_chrome.mov 8.9 MB

resize_jank_chrome.mov 8.9 MB Download

Deleted: resize_jank_safari.mov 12.7 MB

resize_jank_safari.mov 12.7 MB Download

Moving to a different blocker.

I still want to fix this, but dialogs are typically not resizable and this is not so bad that it needs to block initial launch.

If someone really wants it to block then the fix is to make the dialog non-resizable.

It should be fixed before rolling out a toolkit-views task manager (or mac_views_browser).

Assigning over to sdy@ since I know this is an area of interest, but tagging M-X.

SGTM!

MacViews triage: I can't repro this at all now - the resize is perfectly smooth.

I'm marking this Target-67 for sdy@, but if it's actually Fixed, feel free to mark it as such.

sdy@, could you PTAl comment #11?

I gave this a try. It's *much* smoother but still glitches if you try hard. I want to find out why, but it's low priority, so I'm bumping it to M-69.

** Bulk Edit **

There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.

FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release. 

ccameron@: I found the culprit for the recent regression: 9d18ebb63085f1278540a0d1970be93be2a6265d

It basically just makes window resizing faster, so it probably revealed an existing issue, not a new one :-/.

P.S. You mentioned that you think there's a better bug for window resizing jank, so we can move discussion over there if you find it.

Here's an example of a build with and without 9d18ebb63085f1278540a0d1970be93be2a6265d (the jankier one is with).

Deleted: resize_before_change.mp4 140 KB

	resize_before_change.mp4 140 KB View Download

Deleted: resize_after_change.mp4 149 KB

	resize_after_change.mp4 149 KB View Download

Huh. I notice that we do the potential-wait inside windowDidResize, while the RWHV version happens inside -[NSView setFrameSize]. Maybe we should see what happens if we do the delay inside bridged_view_'s setFrameSize?

 Issue 712229  has been merged into this issue.

 Issue 837660  has been merged into this issue.

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

commit a5d0643352de46304b2c8b8deeecdc57edc2d860
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed May 23 00:45:14 2018

Don't fake surface sizes on Mac.

This was causing window resize jank. This hack was added in r364897, and
it's unclear to me if it's needed on Mac. Removing it seems to work, but
I wish I had more context.

Bug:  682825 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I1d9e1224297d78f3c5a08a6774acbe816a6e1c81
Reviewed-on: https://chromium-review.googlesource.com/1069037
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560859}
[modify] https://crrev.com/a5d0643352de46304b2c8b8deeecdc57edc2d860/components/viz/host/renderer_settings_creation.cc

Can this be marked as fixed if nothing else is pending?

Able to reproduce the issue on Mac 10.13.3 using chrome reported version #68.0.3410.0 from the merged issue id: 837660.

Tested the fix on Mac 10.13.3 using Chrome version #68.0.3438.0 as per the merged issue id: 837660 from comment #21.
Attaching screen cast for reference.
Observed that resizing of window is not smooth and Cocoa controls jump around, which seems to be the issue.

sdy@ - Could you please check the attached screen cast and please help us in confirming the fix.
Thanks...!!

Deleted: 682825.mp4 11.1 MB

	682825.mp4 11.1 MB View Download