Unable to reproduce this issue on reported version 65.0.3325.146 using Mac-book Air,Pro 10.13.3 with steps mentioned in comment#0. Attaching screencast for reference.

1. Navigated to https://www.theverge.com/ and opened devtools
2. Selected inspect option and observed fast response only.

This might be specific to iMac only. ET team do not have iMac to test this issue. Looks  like iMac is not available with in-house team as well..still routing to the team to check with other teams and try for a repro on iMac. Hence adding TE-NeedsTriageFromHYD.

Thanks!

Deleted: 821020.mp4 4.9 MB

	821020.mp4 4.9 MB View Download

I was able to reproduce this on my MacBook Pro (late 2013, El Capitan 10.11.6) too, but it's most prevalent when DevTools was detached (in its own window). The performance is still much better than on my new iMac.

We are unable to reproduce in MacBook Air 10.13.3.As per comment #2 & 3 issue reproduce on Imac and MacBook Pro 10.11.6.In-House team not having the imac and  all systems upgraded to 10.13.3 as per policy.

As per inventory requesting some one from MTV team to please check the issue in imac. Hence adding the respective label for it to triage further.

Thank You!

I have this same issue. I'm using an iMac and as soon as I installed Chrome 65, inspecting in the Dev Tools became almost unusably slow. I uninstalled and reinstalled Chrome 64 and the web inspector is super fast, but when Chrome auto-updates back to 65, inspecting is super slow again.

Here's my screen capture. I also used The Verge for consistency, but the problem exists on every other website as well. I'm using Chrome Version 65.0.3325.181.

Deleted: chrome bug.mp4 2.0 MB

	chrome bug.mp4 2.0 MB View Download

Do you use 5K iMac?
Could you go to chrome://tracing, click record, select "Javascript and rendering", move mouse around with inspect and then attached captured trace?

I am not using a 5K iMac. I have a 27-inch, Late 2012 iMac with a 2.9 GHz Intel Core i5 processor and 12 GB 1333 MHz DDR3 Memory. I am running OS X El Capitan version 10.11.6. I have attached a captured trace here.

Deleted: trace_Mon_Apr_02_2018_8.18.41_AM.json.gz 9.6 MB

trace_Mon_Apr_02_2018_8.18.41_AM.json.gz 9.6 MB Download

 Issue 828875  has been merged into this issue.

User from the duplicate running Chrome 67.0.3388.0, iMac 27" 5K Late 2015, Mac OS 10.13.3:
"This has been a problem ever since upgrading to High Sierra. 

Lag only appears when working on retina display. When moving things over to a 1080p monitor, problem resolves itself with no lag."

I was unable to reproduce on a MacBook Pro undocked, will try on a iMac when possible.

Deleted: trace_Chrome_Lag.json.gz 8.9 MB

trace_Chrome_Lag.json.gz 8.9 MB Download

The slow-down is triggered by color correction.  On a machine with an sRGB display profile, everything is fast. To repro the bug on any machine, start chrome with the flag: --force-color-profile=color-spin-gamma24 
The flag will screw up the colors of web pages, but it will force an SRGB to display profile conversion, which is the root of the problem.

It seems there is a caching problem because each compositor tile is re-color-correcting the entire canvas.  This means the color correction is O(N^2) when it should be O(N). Where N is the number of compositor tiles (roughly proportional to the size of the window).  

I'm not sure why we're getting this O(N^2) behavior.  There is a color-correction cache that is supposed to resolve this.  Another part of the problem is that the current implementation of the overlay does not allow the overlay canvas to be GPU-accelerated, so the color correction is forced to happen on the CPU.

I think the best solution would be to simply disable the color correction of canvases on the dev tools overlay layer (do we really need the highlights to be an accurately calibrated shade of blue?).  That's the way it used to be a few releases ago, and no one noticed the difference as far as I know. Any objections?

Wow. Switching my display to use an sRGB profile made all the difference. Everything is super fast again.

>> I think the best solution would be to simply disable the color correction of canvases on the dev tools overlay layer (do we really need the highlights to be an accurately calibrated shade of blue)?

By all means, disable ahead. We don't need precise highlight colors, but we care about the speed a lot. Thank you for looking into it. I'd want to merge it into M67...

Someone mentioned this issue on one I reported recently (#826598), I think they are related. Switching to an sRGB colour profile completely eliminated the delay when inspecting elements, and the repaint delay when resizing the window is much less obvious (although still present).

https://bugs.chromium.org/p/chromium/issues/detail?id=826598

+cc ccameron@ for mac color correction pathology

Re #17, this was reported on Chrome 65, and almost nothing for color conversion changes from Chrome 64 to Chrome 65, so perhaps we could bisect?

This is a combination of things -- the performance is poor only when GPU rasterization is disabled.

 Issue 827816  has been merged into this issue.

It turns out that  issue 827816  is the same as this issue -- canvas animation is slow because of SW raster and SW canvas and color conversion.

The root issue appears to be  issue 791828  -- I'll verify that the fix for that works.

I explored the solution of disabling color correction on the overlay (As stated in #17), and it turned out to be a bad idea.  All the pumbing for bypassing color-correction (legacy mode) has been ripped out, and now many code paths are simply not designed to work with non-color managed image data.  This is good design and we should not backtrack on it.

I think ccameron@ is on a better track.

@ccameron: Another possible solution that I began implementing (currently put on hold) is to modify SkColorSpaceXformCanvas::prepareImage() to make it only color-correct the portion of the image that is exposed in the current compositor tile.  That would bring color correction down to O(N) instead of O(N^2), but it would be bad for caching.  I think figuring out how to get cache hits is the preferred solution.

Merging into  issue 791828 , which will be fixed in 67.

With that fix in, I think this is fixed (please verify on Canary). Unfortunately the fix also broke a bunch of stuff, so productivity--.