Reland again "Start gpu channel and compositor mojo pipe collection eagerly"
[email protected]
TBR=piman
SHERIFFS: This changes timing in the renderer, if (probably ChromeVOX)
tests get flaky they should be disabled please instead of reverting
this.
The flaky tests causing the last iteration of revert were disabled
in https://crrev.com/c/1361585.
This reverts commit d38eb8e01e09dc05802b062bf159f86942fce09e.
Original change's description:
> Start gpu channel and compositor mojo pipe collection eagerly
>
> When a RenderWidget is frozen, its compositor is stopped. However when
> the main frame is being navigated, we want to start requesting mojo
> pipes for the gpu and display compositor immediately so that it can
> happen in parallel with the navigation loading.
>
> Previously, we just always did this when creating a RenderWidget, and
> left them active when freezing the RenderWidget. After 678f025f7cde75
> however, we don't, and this causes time-to-first-pixels regressions
> on navigation.
>
> So we add a WarmupCompositor() method to RenderWidget, and call this
> from RenderFrameImpl::CreateFrame() when it makes the provisional
> frame, and the WebFrameWidget, since we expect to make use of the
> main frame RenderWidget shortly.
>
> Then, if RenderFrameImpl::FrameDetached() occurs, due to the
> navigation failing, we will AbortWarmupCompositor() to drop the
> mojo pipes instead of holding onto them indefinitely.
>
> This recovers the loading regressions introduced, while also not
> allocating mojo channels for frozen RenderWidgets indefinitely.
>
> In order to do this reasonably, we drop the "callback" from the
> request to RenderThreadImpl::RequestNewLayerTreeFrameSink so that
> it always returns something immediately. This way RenderWidget
> does not need to worry about having a task run to collect the
> new frame sink, and ordering with tasks from the compositor to
> collect it.
>
> [email protected]
>
> Change-Id: I6007e26e1622006652ce3619cdd080539d11e7b0
> Bug: 905191
> Reviewed-on: https://chromium-review.googlesource.com/c/1341073
> Commit-Queue: danakj <[email protected]>
> Reviewed-by: danakj <[email protected]>
> Reviewed-by: Daniel Cheng <[email protected]>
> Reviewed-by: Antoine Labour <[email protected]>
> Cr-Commit-Position: refs/heads/master@{#610909}
Change-Id: I100c65758b673a27f7d90bdbd6369abf8e8c608f
Reviewed-on: https://chromium-review.googlesource.com/c/1361598
Reviewed-by: danakj <[email protected]>
Commit-Queue: danakj <[email protected]>
Cr-Commit-Position: refs/heads/master@{#613670}diff --git a/content/renderer/render_thread_impl.h b/content/renderer/render_thread_impl.h
index a831902..a9d0667 100644
--- a/content/renderer/render_thread_impl.h
+++ b/content/renderer/render_thread_impl.h
@@ -268,7 +268,7 @@
using LayerTreeFrameSinkCallback =
base::OnceCallback<void(std::unique_ptr<cc::LayerTreeFrameSink>)>;
void RequestNewLayerTreeFrameSink(
- int routing_id,
+ int widget_routing_id,
scoped_refptr<FrameSwapMessageQueue> frame_swap_message_queue,
const GURL& url,
LayerTreeFrameSinkCallback callback,
@@ -280,7 +280,7 @@
blink::AssociatedInterfaceRegistry* GetAssociatedInterfaceRegistry();
std::unique_ptr<cc::SwapPromise> RequestCopyOfOutputForLayoutTest(
- int32_t routing_id,
+ int32_t widget_routing_id,
std::unique_ptr<viz::CopyOutputRequest> request);
// True if we are running layout tests. This currently disables forwarding
