GitLab

We are having issues where starting a GPU process consistently fails on
some systems. Currently OOP-D runs the display compositor in the GPU
process always. This includes when both hardware acceleration and
SwiftShader are disabled. If we can't start the GPU process, we can't
run the display compositor and Chrome crashes.

This CL changes where the VizCompositorThread runs if the GPU access is
disabled on Windows. We start the thread after giving up on the GPU
process and create FrameSinkManagerImpl + dependencies on it.

Also fix chrome://gpu page so that OOP-D and surface sync features are
still correct if |gpu_access_blocked| is true.

There is a lot of peripheral cleanup and code reuse possible as a follow
up to this CL. It's not attempted here to make this easier to merge back
to M69.

Bug: 849639
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: Ica6a3ec5b0e7951cb6807b135df4b4cfe410e394
Reviewed-on: https://chromium-review.googlesource.com/1158723Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580241}