Fix OOP-D handling of GPU crash.

This CL fixes how the browser renderer host code handles a GPU crash on
Windows with OOP-D. We were clearing both the fallback and primary
surface ID in DelegatedFrameHost on GPU crash. The SurfaceLayer primary
SurfaceId wasn't set until it went through the embed flow again, which
didn't happen consistently after a GPU crash unless the user was
interacting with the browser UI. The result is an background color frame
until the user does something to trigger the embed flow. The browser
still wants to embed the same renderer SurfaceId, so only clear the
fallback SurfaceId and wait for the renderer to submit a new
CompositorFrame.

With OOP-D we always want to call OnLostResources() for GPU process
crashes. For GPU compositing this is handled by losing the main thread
context provider. With software compositing there is no main thread
context provider. Add a call to OnLostResources() to handle the software
compositing case. In a future CL we should split OnLostResources() into
OnLostSharedContext() and OnLostGpuProcess() to differentiate between
the two reasons resources can be lost.

ContextObserver::OnLostResources() is only called if there is a shared
main thread context provider that gets lost. Without OOP-D, that context
provider only exists for Chrome OS and even then only sometimes. We
don't use shared main thread context on other platforms, so
OnLostResources() hasn't been reliably called in a while. This could be
fixed as a follow up, or we could just wait for OOP-D to launch
everywhere. It's not crucial to clear the fallback SurfaceId without
OOP-D as the Surface still exists, there just might be GL resource
errors.

Bug: 827242
Change-Id: I2f203fa827225b1607d8b5436375818625b01cad
Reviewed-on: https://chromium-review.googlesource.com/1143138
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576527}
2 files changed