Using the per-revision bisect providing the bisect results,
Good build:61.0.3125.0(Revision:478135).
Bad build:61.0.3126.0(Revision:478483).

You are probably looking for a change made after 478388 (known good), but no later than 478389 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/21886543a0cbedeb869fb68944e13ef613cedceb..d3b9d651b0b0ea57990ecf8e0991f39f2870c4fa

From the CL above, assigning the issue to the concern owner

@staraz: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Reviewed-on:  https://chromium-review.googlesource.com/527478
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Not in Mac 10.12.3 and Able to reproduce in latest Canary #61.0.3138.0
Adding Release Block-Stable for this issue.Please remove if not the case.

This seems to be related to 680777.

boliu@: Could you take a look?

No, I don't work on desktop. Plus it landed on your CL

I checked out the revision before my CL and the regression persists.

jbauman@: It seems that the GPU channel is not re-established when the browser
window is minimized but the task manager is visible. Could you take a look?

I'm getting the same bisect as  rbasuvula - that r478389 is at fault.

I checked out and built the parent of r478389
(https://chromium.googlesource.com/chromium/src/+/21886543a0cbedeb869fb68944e13ef613cedceb) and was able to reproduce the same problem 10/10.

What platform are you testing on? On Windows 10 I can't repro it on my own build of r478388, but it always happens on r478389.

Linux

If I move GetSurfaceManager()->RegisterBeginFrameSource(begin_frame_source, compositor->frame_sink_id()); below the creation of the DirectCompositorFrameSink then it works. Is it possible the BeginFrameSource isn't being properly connected when it's first created?

Before I moved BeginFrameSource out of Display, there was a comment in
cc::Display::Initialzie saying "This (RegisterBFS) must be done in Initialize()
so that the caller can delay this until they are ready to receive a
BeginFrameSource. (https://chromium-review.googlesource.com/c/527478/9/cc/surfaces/display.cc#b89)

Instead of "BeginFrameSource isn't being properly connected when it's first
created", I'm suspecting that by registering the BFS before creating the
DirectLayerTreeFrameSink, we miss the first BeginFrame after restarting the
GPU process.

I uploaded a CL for this change.

After killing the gpu process while the browser window minimized, the gpu process
restarts but the task manager window isn't getting BeginFrames until the browser
window is visible again.

Having the browser window in the background but without a renderer (i.e.
displaying the sad tab) would lead to the same unresponsive task manager.

Registering BeginFrameSource after creating DirectLayerTreeFrameSink doesn't
seem to fix it for me anymore.

My suggestion: Checkout back to a revision where it does, and use that to debug down to the root cause, as you can see what is different with/without that change, and from there to TOT as well.

Note: The bug is not reproducible while chromoting.

I suspect Chromoting uses software compositing?

The bug is fixed if I move RegisterBeginFramesource from
GpuProcessTransportFactory::EstablishedGpuChannel to
DirectLayerTreeFrameSink::BindToClient (experimental CL: https://chromium-review.googlesource.com/c/550235/7. I didn't change the Android code so Android bots are likely to fail).

We didn't do this in the first place because we wanted register and unregister
inside one class. I'll continue looking for an appropriate place to put these.

I'd like to understand what the problem is? We can find a better solution if we understand the problem?

I'm still looking for a clear explanation for the cause, but I believe it has something to do with a comment that used to be in cc::Display::Initialize (where we used to call RegisterBeginFrameSource):
"This (RegisterBFS) must be done in Initialize()
so that the caller can delay this until they are ready to receive a
BeginFrameSource." (See comment #10)

From the comment, the explanation would be the caller (client) is not ready to receive BeginFrame when the BFS is registered. I'll dig deeper and see what "not ready" means here

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

commit 1c17648285c4edd77a7148e21c32918e5c46c82c
Author: Alex Zhang <staraz@chromium.org>
Date: Mon Jul 10 02:17:56 2017

Do not remove entry from |frame_sink_source_map_| when client is unregistered.

Currently, FrameSinkManager::UnregisterFrameSinkManagerClient removes
the entry associated with |frame_sink_id| from |frame_sink_source_map_|
if the |frame_sink_id| does not have any children. This would result in
a client not connected with a BeginFrameSource when it is unregistered
and re-registered with the same FrameSinkId.

This CL removes the lines that removes the entry from |frame_sink_source_map_|
if the |frame_sink_id| has no child in
FrameSinkManager::UnregisterFrameSinkManagerClient. It also adds a unit
test to verify that the client gets reconnected to the BeginFrameSource
after unregistering and re-registering.

Bug:  735805 
Change-Id: I93ae860b1192e23aa116749d0bbcdb553ddc2246
Reviewed-on: https://chromium-review.googlesource.com/563705
Commit-Queue: Xingyu Zhang <staraz@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485172}
[modify] https://crrev.com/1c17648285c4edd77a7148e21c32918e5c46c82c/cc/surfaces/frame_sink_manager.cc
[modify] https://crrev.com/1c17648285c4edd77a7148e21c32918e5c46c82c/cc/surfaces/frame_sink_manager_unittest.cc