reporter@ - Thanks for filing the issue...!!

Could you please provide consistent repro steps with expected and actual results to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

There are a bunch of tabs open in my profile.

All I can say is that this problem started after the most recent update of Chrome.

I work for Google, if you work there too I can bring my machine and let you get whatever data you need.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Thanks for the trace. I'm seeing an unusual amount of browser process activity in DisplayScheduler::BeginFrame but beyond that I'm not sure how to triage this one. +vmiura who would be right to take a look?

I started seeing an issue - probably similar to this - on my MacBook Air around M66. It took me a few days to figure out why my battery life had dropped by about a factor of 10.
The usability of Chrome also dropped off a cliff - everything about the UI became extremely sluggish.

I'm trying to see if I can find any useful hints.
So far it seems to somewhat, but not entirely, persist if I open a "Guest" session in the same chrome instance and close the original session.
But I can't say for sure whether it reproduces on a new user-data-dir - it seems less bad.

According to Chrome's task manager, the browser process uses anywhere from 30-80%+ at any given time.

brianderson@, any ideas? something seems to be going very wrong int the display scheduler.

Update: it has been fine on a new user-data-dir. (Battery life is back to normal.)

I still have the old one backed up in case I can use it to help debug.

Moving owner to Kai for triage/routing.

cc+=Sadrul since he recently fixed a high CPU usage bug related to LatencyInfo accumulation, which might be the same root cause as this bug.

suresh, are you still seeing this issue?

I just tried loading up that old profile again, in Chrome Canary (69.0.3474.0), and - amazingly - it still might be reproducible. However I can't tell for sure. While I have my Google accounts sign-in page in the foreground tab, I see about 20% CPU in the browser process + 18% CPU in that renderer process. But when I open a new tab and switch to it, both are under 1%.

I'm still seeing the issue.

I worked around it temporarily by switching to Safari, while awaiting the fix for Chrome.

+ccameron@ +sunnyps@

Was this with mac-views?

I notice a few unfinished 'WaitSyncToken' in the gpu-process. Could that be related?

One quick note I would like to add: the task-manager in chrome (at least the one with views) is fairly expensive as it updates, and can show an increased cpu-usage in the browser process. If you close chrome's task-manager, and check the browser-cpu usage from the system tools, that would give you a more real number.

I was using mac-views, however after replacing my user-data-dir I was still using mac-views and didn't see the issue.

Unfortunately I'm not seeing an issue anymore after signing into Google and signing back out. I think it was a transient issue with the Google accounts sign-in page causing a lot of CPU usage, and the task manager may have been causing the browser process usage. So this probably was not the same issue I saw originally.

I suppose that could have been a Dice issue? Since it seemed somehow tied with the account login.

The original issue is from Chrome 65, which did not have MacViews.

I'm currently using 67.0.3396.87 version of Chrome. Does it have MacViews?

I don't think 67 has MacViews enabled by default. And in any case, I don't think this issue is tied to MacViews at all.

Last night I remembered that I've had one other major system change since I had the issue (although I still don't know if it was the same issue Suresh has). I upgraded from 10.13.4 to 10.13.5 recently.

Suresh: which macOS version are you on? (in case it's relevant to the issue)

I don't really know how to move forward with this. ccameron, do you have any ideas?

(BTW, I don't think we have ever determined for sure that this was really a GPU-related bug. It just seemed suspicious from the trace.)