I forgot to add that this also happens on 63-Canary. I tried to transfer all of my data to Canary and see if it was 61 that was the problem, and it is for sure the theme. I've uninstalled the theme and Chrome runs fine now.

Able to reproduce this issue on reported 61.0.3163.100 and on latest canary 63.0.3226.0 using Windows 10,Mac 10.12.6 and Ubuntu 14.04 with steps mentioned in comment#0.

Manual Bisect Info:
===============
Good Build: 61.0.3142.0
Bad Build: 61.0.3144.0

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

Review-Url: https://chromium.googlesource.com/chromium/src/+/a870f3a000f480d9dea3399f4e011c080ac669aa

@pkasting: Please confirm the bug and help in re-assigning to correct owner if it is not related to your change.

Thanks!!

Have the same issue on linux, 
Appeared somewhere between 60.0.3112.113 and 61.0.3163.79. Short freeze when switching tabs, disappears when theme is disabled.

Tried other themes, got differents amount of lag. Some induced no lag, others even larger lag

I continued the bisect, and narrowed to 482904:
You are probably looking for a change made after 482903 (known good), but no later than 482904 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/8b4643f67dc1c6b142a152aa2b76c771287e3a22..1894d423068be735560e0171922c833c4091b5d1

So apparently this bug is related to color correction, however running with --enable-legacy-color-correct-rendering changes nothing

Any update on this?
Themes are pretty much unusable due to the lag until this gets fixed.

It now slows down typing in the URL bar. Themes are broken.

->ccameron per comment 6

mcasas also pointed out an issue on CrOS where low-end CPUs combined with high-res displays combined with non-sRGB color profiles resulted in very slow display.

The non-exhaustive menu of fixes is as follows:

1. The ui::Compositor historically has never had WCG content, so we could just tell it to always use sRGB. That is a change at [1].

2. I have all of the infrastructure in place to detect when a layer only has sRGB content and avoid doing raster-time color conversion for such layers (see issue 719735). We could enable that on some platforms [2]. I don't have that enabled for two reasons
   2.A: It regresses battery life on Mac
   2.B: It could result in slightly different results across seams
Of layers that have any images, 91% of them have only sRGB content (see UMA Renderer4.ImagesPercentSRGB).

3. We could just pass a "force rasterization into sRGB" flag for consumption at [3].

I personally vote for the following:
- We should do 1, because it quickly fixes the themes issue and regresses (I think) nothing. I need to verify that. If we ever plan to add WCG content for the UI, then we can re-examine at that point. We also need to know when we do GPU raster for the UI (do we?).
- We should combine 2 and 3 and add a "if using software raster, then force raster of sRGB content into sRGB", which should take the pressure off of weak CPUs.

[1] See host_->SetRasterColorSpace at https://cs.chromium.org/chromium/src/ui/compositor/compositor.cc?rcl=c111da46685b52ab39e2d73245f26e4b498730c4&l=368

[2] This gets as far as DiscardableImageMap (just for histograms), but doesn't get plumbed as far as is needed.
https://cs.chromium.org/chromium/src/cc/paint/discardable_image_map.h?rcl=4e62b05b80217992dee03aab833bcd3085d085dd&l=60

[3] Consume the flag here: https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?rcl=c111da46685b52ab39e2d73245f26e4b498730c4&l=1448

Also, could you navigate to about:gpu, print the result to a PDF, and attach it.

(Just to make sure that I'm targeting this correctly).

(that is, just on Canary, it has more information).

@#10: "We also need to know when we do GPU raster for the UI (do we?)". We don't currently.

 Issue 790741  has been merged into this issue.

I installed this theme on my workstation and reproed the problem in stable (Version 62.0.3202.94 (Official Build) (64-bit)) however I noticed that on canary the issue is much harder to spot - the delays are much shorter.

I grabbed an ETW trace on stable and it showed delays of 1.2 s, with most of the time spent in functions called from chrome.dll!_sk_start_pipeline_hsw - unfortunately this function doesn't include the necessary metadata for stack walking so the call site of chrome.dll!_sk_start_pipeline_hsw is lost. I'll file a bug for the bad stack-walk metadata.

Canary seemed to be faster although the total CPU consumption was similar. I found no CPU time in chrome.dll!_sk_start_pipeline_hsw and very modest CPU time in chrome_child.dll!_sk_start_pipeline_hsw_lowp.

Option #1 seems like a good choice, at least to unblock us for now. This issue is serious enough to push people away from Chrome. On machines where the slowdown is less visible it's probably still doing terrible things to battery life.

Recently darin@ had a very slow scrolling experience on Dell XPS 13 with Chrome 62, which was much better on Canary.  I don't recall if there was a theme installed, but wonder if it could also be a UI rendering perf issue.

ccameron@, with [1] would we then do color conversions for the UI layers at compositing time?

The dark theme (v3) has large textures for the tab backgrounds, tabstrip, window background etc.  Are we missing caching of color corrected images in this path?

Re #19: Don't worry, I will investigate the problem.

Issue 786922 has been merged into this issue.

^ bug 786922 is about a similar perf regression with the "Black Wood" theme. There's a Chrome trace attached there as well.

The root cause of the bug is as follows:

Our cc::ImageDecodeCache will only cache images that need a lazy decode.

Color conversion relies on having the cc::ImageDecodeCache cache color converted images.

The theme images in the browser process are pre-decoded (they do not need a lazy decode), so they are not stored in this cache, even though they need color conversion.

And so we re-color-convert all UI images for every draw call -- about 30 times per tab-switch (and lots just when hovering over the tabstrip). This ends up as SkImage_Raster::onMakeColorSpace being called over and over.

The long-term fix here is to have cc::ImageDecodeCache include non-lazy-decode images (there is already  issue 660975  filed on this issue for GPU raster, to avoid repeated re-upload).

The short-term fix (verified to work locally) is to force an sRGB color profile for rasterization in the ui::Compositor. That fix is very safe and can be merged back as far as we'd like (including stable).

The ideas discussed in #10 can also be considered for the medium-term (not something to merge back).

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

commit a9634625b03962f7fdb714153a6fb8564da4084b
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Dec 04 21:39:58 2017

Rasterize ui::Compositor to sRGB

The UI theme images will miss color conversion caching, resulting in
repeated conversions and poor performance.

Bug:  769677 
Change-Id: Icfeafb9c9418cf03bfbfaae62cf98c5ad07e0f6d
Reviewed-on: https://chromium-review.googlesource.com/806641
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521465}
[modify] https://crrev.com/a9634625b03962f7fdb714153a6fb8564da4084b/ui/compositor/compositor.cc

I talked to the release managers, and this is not a candidate for the initial 63 push.

After a couple of days in Canary I'll merge to 64 and 63, and if we do any 63 respins, it will pick up this change.

Thank you  ccameron@. Please request a merge to M63 and M64 and wait for approval before merging. 

The NextAction date has arrived: 2017-12-06

Adding merge requests.

M63 is already in stable and we're only raking CRITICAL merges in. This was regressed in M61 (not M63 regression), sorry it will have to wait for M64. Please let me know if there is any concern here.

By the way, is there a metric that exists that we would see movement in from this improvement (or from a regression)?

Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

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

commit 1a22a3744fc1a92a45cb8b0161038cc48bb5396b
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Dec 08 20:54:54 2017

Rasterize ui::Compositor to sRGB

The UI theme images will miss color conversion caching, resulting in
repeated conversions and poor performance.

TBR=ccameron@chromium.org

(cherry picked from commit a9634625b03962f7fdb714153a6fb8564da4084b)

Bug:  769677 
Change-Id: Icfeafb9c9418cf03bfbfaae62cf98c5ad07e0f6d
Reviewed-on: https://chromium-review.googlesource.com/806641
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521465}
Reviewed-on: https://chromium-review.googlesource.com/817708
Cr-Commit-Position: refs/branch-heads/3282@{#105}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/1a22a3744fc1a92a45cb8b0161038cc48bb5396b/ui/compositor/compositor.cc

How is the change looking in canary? 

Canary is fixed, and there haven't been any issues.

Tested the issue on windows 10 , Mac OS 10.12.6 and Ubuntu 14.04 using chrome M64 #64.0.3282.24 and observed that issue is fixed.

No delay/lag is seen on switching tabs after adding dark theme to chrome.

Attached screencast for reference.

Adding TE-Verified labels.

Thanks!

Deleted: 769677_CL.mp4 2.0 MB

	769677_CL.mp4 2.0 MB View Download

Yay! Thanks! When will this be shipped?

Approving merge to M63 branch 3239 per internal email thread and per comments #35 and #36. Please merge ASAP. Thank you.

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

commit d93b8f9ca0aeeec9a6eb8311ae679b93c8551e98
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Dec 13 00:58:42 2017

Rasterize ui::Compositor to sRGB

The UI theme images will miss color conversion caching, resulting in
repeated conversions and poor performance.

TBR=ccameron@chromium.org

(cherry picked from commit a9634625b03962f7fdb714153a6fb8564da4084b)

Bug:  769677 
Change-Id: Icfeafb9c9418cf03bfbfaae62cf98c5ad07e0f6d
Reviewed-on: https://chromium-review.googlesource.com/806641
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521465}
Reviewed-on: https://chromium-review.googlesource.com/823577
Cr-Commit-Position: refs/branch-heads/3239@{#672}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/d93b8f9ca0aeeec9a6eb8311ae679b93c8551e98/ui/compositor/compositor.cc

Merged!

Thank you so much!

Rechecked this issue on Windows 10, Mac 10.12.6, Ubuntu 14.04 using chrome version 63.0.3239.108. Merge is working as intended. No lag is observed when switched tabs on chrome which has a dark theme applied.

Thanks.!