New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 704972 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 697864



Sign in to add a comment

ViewHostMsg_SwapCompositorFrame can't contain nested IPC messages

Project Member Reported by samans@chromium.org, Mar 24 2017

Issue description

Once we switch to MojoCompositorFrameSink, we can't send nested IPC messages with the frame. The following messages can be nested inside the swap message:

FrameHostMsg_VisualStateResponse
ViewHostMsg_DidFirstPaintAfterLoad
ViewHostMsg_WaitForNextFrameForTests_ACK
ViewHostMsg_DidFirstVisuallyNonEmptyPaint
FrameHostMsg_HittestData
 

Comment 1 by samans@chromium.org, Mar 24 2017

Blocking: 697864
Cc: fsam...@chromium.org samans@chromium.org piman@chromium.org
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 24 2017

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

commit 087035f0efd4da20592c02b64fddaa7bfee761c6
Author: samans <samans@chromium.org>
Date: Fri Mar 24 19:20:03 2017

Remove ViewHostMsg_DidFirstPaintAfterLoad

ViewHostMsg_DidFirstPaintAfterLoad is currently stored inside
ViewHostMsg_SwapCompositorFrame, but once ViewHostMsg_SwapCompositorFrame
is mojoified, we don't want to have IPC messages sent using mojo calls.
Fortunately ViewHostMsg_DidFirstPaintAfterLoad can go away after the
introduction of content_source_id in CompositorFrameMetadata a few
weeks ago.

BUG= 704972 

Review-Url: https://codereview.chromium.org/2770873002
Cr-Commit-Position: refs/heads/master@{#459514}

[modify] https://crrev.com/087035f0efd4da20592c02b64fddaa7bfee761c6/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/087035f0efd4da20592c02b64fddaa7bfee761c6/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/087035f0efd4da20592c02b64fddaa7bfee761c6/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/087035f0efd4da20592c02b64fddaa7bfee761c6/content/common/view_messages.h
[modify] https://crrev.com/087035f0efd4da20592c02b64fddaa7bfee761c6/content/renderer/render_frame_impl.cc

Project Member

Comment 3 by bugdroid1@chromium.org, Apr 5 2017

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

commit d8ecdc4a0429d984fde83e08a1bb343af2d6851b
Author: samans <samans@chromium.org>
Date: Wed Apr 05 03:05:02 2017

Send FrameSwapMessageQueue's messages with a separate IPC

We can't put messages inside ViewHostMsg_SwapCompositorFrame once it's
mojoified, so those messages need to be sent separately. In order
to achieve this, I added an integer token to CompositorFrameMetadata
and send the same token with the messages to the browser. The browser
uses the token to match frames and messages and once both the frame and
its messages arrive, the messages are processed.

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
BUG= 704972 

Review-Url: https://codereview.chromium.org/2789773003
Cr-Commit-Position: refs/heads/master@{#461962}

[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/cc/ipc/compositor_frame_metadata.mojom
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/cc/ipc/compositor_frame_metadata_struct_traits.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/cc/output/compositor_frame_metadata.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/browser/bad_message.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/common/view_messages.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/renderer/gpu/frame_swap_message_queue.cc
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/renderer/gpu/frame_swap_message_queue.h
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/renderer/gpu/queue_message_swap_promise.cc
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/content/renderer/gpu/renderer_compositor_frame_sink.cc
[modify] https://crrev.com/d8ecdc4a0429d984fde83e08a1bb343af2d6851b/tools/metrics/histograms/histograms.xml

Project Member

Comment 4 by bugdroid1@chromium.org, Apr 7 2017

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

commit a1c5ca581b5d6b97b4b150fb32125055a678dca2
Author: samans <samans@chromium.org>
Date: Fri Apr 07 00:08:17 2017

Deserialize frame_token in CompositorFrameMetadata's struct traits

In my last CL I added the serialization code but not deserialization.

TBR=danakj@chromium.org
BUG= 704972 

Review-Url: https://codereview.chromium.org/2801603009
Cr-Commit-Position: refs/heads/master@{#462697}

[modify] https://crrev.com/a1c5ca581b5d6b97b4b150fb32125055a678dca2/cc/ipc/compositor_frame_metadata_struct_traits.cc
[modify] https://crrev.com/a1c5ca581b5d6b97b4b150fb32125055a678dca2/cc/ipc/struct_traits_unittest.cc

Blocking: 601863
Labels: displaycompositor
Owner: samans@chromium.org
Status: Fixed (was: Untriaged)
This is FIXED I believe! Thanks Saman!
Components: Internals>MUS Internals>Compositing
Blocking: -601863
Components: -Internals>MUS Internals>Services>WindowService

Sign in to add a comment