GetSnapshotFromBrowser was historically a mechanism to get what's actually rendered vs some intermediate surface inside. It is used by gpu team, for example, to test the rendering. +kbr@ for this.

I filed a similar bug last week.  crbug.com/810037 

kbr's response:

"Yes, for end-to-end pixel tests in Chrome it is absolutely necessary to use OS-level screenshot mechanisms, and to know when the requested frame has reached the screen.

Various Telemetry-based pixel tests that run on the GPU bots rely on this working. There is also a new SnapshotBrowserTest which attempts to stress test this mechanism. Simply deleting the sequence number from LatencyInfo causes one of these tests to reliably fail."

I took a look and I think, currently, there is no longer a use case for GetSnapshotFromBrowser(). All call points from tests use "true" for its 2nd argument, which means that it is getting the capture from the surface (CopyOutputRequests), and not the OS directly. That makes it functionally identical to the CopyOutputRequests (sans API differences).

That said, GetSnapshotFromBrowser() does one thing extra: It forces the renderer to redraw with a specific LatencyInfo. It appears this is what's allowing tests to correlate a snapshot in a specific sequence-of-operations.

So, I propose we remove GetSnapshotFromBrowser() from RenderWidgetHostImpl, and replace it with a standalone utility function in src/content/test or thereabouts. It's basically a performance test utility. I don't see that CopyOutputRequests wouldn't satisfy any normal, non-test browser screen capture scenario, including the DevTools ones. Sound good?

The GPU tests still pass false for the second argument via DevTools' Page.captureScreenshot API:

https://chromedevtools.github.io/devtools-protocol/tot/Page#method-captureScreenshot

https://cs.chromium.org/chromium/src/content/browser/devtools/protocol/page_handler.cc?q=GetSnapshotFromBrowser&sq=package:chromium&g=0&l=620

through this call chain:

https://cs.chromium.org/chromium/src/content/test/gpu/gpu_tests/pixel_integration_test.py?q=pixel_integra&sq=package:chromium&g=0&l=142

https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/browser/tab.py?q=tab.py+Screenshot&g=0&l=111

https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py?q=Screenshot+inspector_backend.py&g=0&l=151

https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_page.py?q=Screenshot+inspector_page.py&g=0&l=139


It's crucial to keep this working on as many platforms as actually support the OS-level screenshots. (I think Aura's been taking the screenshots from the back buffer for some time, which is problematic, but other platforms support the real OS-level screenshots.) Otherwise we will reintroduce a significant gap in automated testing of highly platform-dependent presentation code.