Here are similar tests on a slower machine, OS X 10.11.5:

47.0.2526.80: 5.16s
48.0.2564.103: 17.5s

Deleted: 47.0.2526.80.png 56.2 KB

	47.0.2526.80.png 56.2 KB View Download

Deleted: 48.0.2564.103.png 50.1 KB

	48.0.2564.103.png 50.1 KB View Download

Tested this issue on Windows 7 using chrome version M47-47.0.2526.111 by following steps mentioned below.

1. Navigated to the attached file index.html
2. Performed consistent resizing operation of the browser
3. Observed some rendering in loading the page back to normal.

Attaching screen-cast for reference, Could you please let us know is this is the issue you are talking about? If yes, I am able to repro on chrome 47.0.2526.111 as well. 

Deleted: Recording #23.mp4 2.2 MB

	Recording #23.mp4 2.2 MB View Download

Thank you for the quick response.

I recorded the tests I did comparing 47 and 48. Notice 48 takes much longer to redraw the screen after the resize.

Deleted: 47.0.2526.111.mp4 4.1 MB

	47.0.2526.111.mp4 4.1 MB View Download

Deleted: 48.0.2564.82.mp4 5.1 MB

	48.0.2564.82.mp4 5.1 MB View Download

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Are there any updates for this issue? Please let me know if you need any more information from me. Thanks.

Could you please confirm are you seeing this issue on latest chrome latest stable M52-52.0.2743.82? and please let us know on which Linux flavor you are using.

Hi brajkumar,

Adding one more data point in addition to what is reported above.  I'm using Mac OS X 10.11.6 running Google Chrome (Version 52.0.2743.82 64-bit) and seeing the same issue.

Kevin

Here is the same test on 52.0.2743.82. I am using Arch Linux (64 bit), kernel version 4.6.4-1.

Deleted: 52.0.2743.82.png 45.6 KB

	52.0.2743.82.png 45.6 KB View Download

Deleted: version.png 56.2 KB

	version.png 56.2 KB View Download

FWIW you can "run" the gist with this URL:

https://rawgit.com/chrismangum/241942ab36e5594398d12829a912f27a/raw/36e3f188a84e811d611cba4d6b489f559ef7aa2c/index.html

I see this odd resize-repaint tearing on Linux in 52.0.2743.82 (Official Build) (64-bit).

First blush, this looks like a layout regression.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

For bisect purposes, range from comment 3: 352221 .. 359700

You are probably looking for a change made after 354213 (known good), but no later than 354220 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/dc2a659b0ad54c3dcb632b876e40a71fa03019e9..e4471ed4dce8f2fc53e3e7f54aa8c4e18b93ea8c

Very likely Levi's change:
https://chromium.googlesource.com/chromium/src/+/585d07fa7ccde4980d159236e3023d1c0fb16f80

As that's linebreaking, assigning this to Koji for now.

I've made several fixes to break-all and break-word since the Levi's CL. Currently on my machine:

Canary 54.0.2826.0: 6655ms
Firefox: 4454ms
Edge: 4145ms

If you change "Xx" to "Xx ":

Canary 54.0.2826.0: 3545ms
Firefox: 6109ms
Edge: 4152ms

So we're faster than Edge/Firefox for words with spaces, while slower for a long word without spaces. This is a result of our optimizations for what we believe common cases are.

Could you confirm that having a 72 chars text without spaces and 50,000 div is a test case and it is not something you expect Chrome to optimize for?

Do you have more real use cases where Chrome is slower?

Closing as there's no further feedback for 2 weeks, and our performance is similar to Firefox/Edge for the provided cases.

Please feel free to add comments if there were any, and we'd be happy to investigate further.