Clean up Mac swap acknowledgement code

Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean that
   the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in
   particular, the CAContextID or IOSurface).

With the consolidation of display paths on Mac, reason 1 is finally
gone. The other reasons remain, and for this reason, Mac still needs
to be slightly different than the other platforms (which use the
GpuCommandBufferMsg_SwapBuffersCompleted IPC, and a callback from
CommandBufferProxyImpl to get the ack).

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call BrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well
(their calls come from the CommandBufferProxyImpl).

In the process of this, move OnGpuSwapBuffersCompleted from being
named OnSwapBuffersCompleted in GpuBrowserCompositorOutputSurface
to being a method of BrowserCompositorOutputSurface (with Gpu in
its name, to indicate the source).

Delete the web of callbacks going through AcceleratedWidgetMac that
were responsible for the delayed swap-ack.

Remove now-unused IPC fields.

Committed: https://crrev.com/4d4a02b8db7c319f26e823fcea22fd2b3797f538
Cr-Commit-Position: refs/heads/master@{#356956}

[ccameron, 2015-10-27 19:27:26]

Description was changed from

==========
Clean up Mac swap acknowledgement code

BUG=546795
==========

to

==========
Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean
   that the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in particular, the
   CAContextID or IOSurface).

With the consolidation of display paths on Mac, reason 1 is finally gone,
so we can remove the supporting code.

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call GpuBrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well.

In the process of this, move OnGpuSwapBuffersCompleted from being
a method of GpuBrowserCompositorOutputSurface to being a method
of BrowserCompositorOutputSurface.

Delete the web of callbacks going through AcceleratedWidgetMac that were
responsible for the delayed swap-ack.

Remove now-unused IPC fields.

BUG=546795
==========

[ccameron, 2015-10-27 19:41:30]

Description was changed from

==========
Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean
   that the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in particular, the
   CAContextID or IOSurface).

With the consolidation of display paths on Mac, reason 1 is finally gone,
so we can remove the supporting code.

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call GpuBrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well.

In the process of this, move OnGpuSwapBuffersCompleted from being
a method of GpuBrowserCompositorOutputSurface to being a method
of BrowserCompositorOutputSurface.

Delete the web of callbacks going through AcceleratedWidgetMac that were
responsible for the delayed swap-ack.

Remove now-unused IPC fields.

BUG=546795
==========

to

==========
Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean that
   the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in
   particular, the CAContextID or IOSurface).
   
With the consolidation of display paths on Mac, reason 1 is finally
gone. The other reasons remain, and for this reason, Mac still needs
to be slightly different than the other platforms (which use the
GpuCommandBufferMsg_SwapBuffersCompleted IPC, and a callback from the
client side of the command buffer to ack swaps).

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call BrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well 
(their calls come from the CommandBufferProxyImpl).

In the process of this, move OnGpuSwapBuffersCompleted from being
named OnSwapBuffersCompleted in GpuBrowserCompositorOutputSurface
to being a method of BrowserCompositorOutputSurface (with Gpu in
its name, to indicate the source).

Delete the web of callbacks going through AcceleratedWidgetMac that
were responsible for the delayed swap-ack.

Remove now-unused IPC fields.
==========

[ccameron, 2015-10-27 19:50:45]

Description was changed from

==========
Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean that
   the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in
   particular, the CAContextID or IOSurface).
   
With the consolidation of display paths on Mac, reason 1 is finally
gone. The other reasons remain, and for this reason, Mac still needs
to be slightly different than the other platforms (which use the
GpuCommandBufferMsg_SwapBuffersCompleted IPC, and a callback from the
client side of the command buffer to ack swaps).

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call BrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well 
(their calls come from the CommandBufferProxyImpl).

In the process of this, move OnGpuSwapBuffersCompleted from being
named OnSwapBuffersCompleted in GpuBrowserCompositorOutputSurface
to being a method of BrowserCompositorOutputSurface (with Gpu in
its name, to indicate the source).

Delete the web of callbacks going through AcceleratedWidgetMac that
were responsible for the delayed swap-ack.

Remove now-unused IPC fields.
==========

to

==========
Clean up Mac swap acknowledgement code

Mac swap acks differ from other platforms for three reasons
1. When a swap ack comes from the GPU process, it does not mean that
   the content is necessarily on-screen yet -- it may be that we will
   need to wait for that content to be drawn into a CAOpenGLLayer.
   For this reason, we created a separate OnSurfaceDisplayed callback,
   which happens when the surface is actually drawn.
2. Smooth resize on Mac requires that the IPCs for swap acks go
   through the GpuProcessHostUIShim (as opposed to the command
   buffer stub, as on other platforms).
3. Swap acks coming from the GPU process carry additional information
   that is needed to get the content on the screen on Mac (in
   particular, the CAContextID or IOSurface).
   
With the consolidation of display paths on Mac, reason 1 is finally
gone. The other reasons remain, and for this reason, Mac still needs
to be slightly different than the other platforms (which use the
GpuCommandBufferMsg_SwapBuffersCompleted IPC, and a callback from
CommandBufferProxyImpl to get the ack).

Instead of calling ImageTransportFactory::OnSurfaceDisplayed, call
instead ImageTransportFactory::OnSwapBuffersCompleted, which will
call BrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted,
which is where all other platforms' swap acks bottom out as well 
(their calls come from the CommandBufferProxyImpl).

In the process of this, move OnGpuSwapBuffersCompleted from being
named OnSwapBuffersCompleted in GpuBrowserCompositorOutputSurface
to being a method of BrowserCompositorOutputSurface (with Gpu in
its name, to indicate the source).

Delete the web of callbacks going through AcceleratedWidgetMac that
were responsible for the delayed swap-ack.

Remove now-unused IPC fields.
==========

[ccameron, 2015-10-27 19:59:25]

ccameron@chromium.org changed reviewers:
+ kbr@chromium.org

[ccameron, 2015-10-27 19:59:25]

More cleanup and code-deleting

[Ken Russell (switch to Gerrit), 2015-10-27 20:03:49]

kbr@chromium.org changed reviewers:
+ jbauman@chromium.org, sunnyps@chromium.org

[Ken Russell (switch to Gerrit), 2015-10-27 20:03:49]

Is there another reviewer who could take this? I'm under a big crunch right now
and won't have time to review this in the next two days before leaving on
vacation and a business trip.

[ccameron, 2015-10-27 20:39:52]

Sure -- jbauman, can you take a look?

[ccameron, 2015-10-28 21:54:48]

ccameron@chromium.org changed reviewers:
+ dcheng@chromium.org, sadrul@chromium.org

[ccameron, 2015-10-28 21:54:48]

Adding sadrul@ for ui/ stamp, dcheng@ for _messages.h stamp.

[dcheng, 2015-10-28 21:55:34]

Yay, removed code!

deletions in gpu_messages.h lgtm!

[jbauman, 2015-10-28 22:27:30]

Generally makes sense; just one question.

https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_mac.mm (left):

https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:542:
latency_info.AddLatencyNumberWithTimestamp(
Is this currently dead? If not, should these latency info components be added
somewhere else?

[ccameron, 2015-10-28 22:37:05]

https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_mac.mm (left):

https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:542:
latency_info.AddLatencyNumberWithTimestamp(
On 2015/10/28 22:27:30, jbauman wrote:
> Is this currently dead? If not, should these latency info components be added
> somewhere else?

They are added through RenderWidgetHostLatencyTracker::OnFrameSwapped ... I
think they were being double-added before (RWHI::FrameSwapped will re-add them
...).

[jbauman, 2015-10-28 22:51:47]

On 2015/10/28 22:37:05, ccameron wrote:
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> File content/browser/renderer_host/render_widget_host_view_mac.mm (left):
> 
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> content/browser/renderer_host/render_widget_host_view_mac.mm:542:
> latency_info.AddLatencyNumberWithTimestamp(
> On 2015/10/28 22:27:30, jbauman wrote:
> > Is this currently dead? If not, should these latency info components be
added
> > somewhere else?
> 
> They are added through RenderWidgetHostLatencyTracker::OnFrameSwapped ... I
> think they were being double-added before (RWHI::FrameSwapped will re-add them
> ...).

RenderWidgetHostLatencyTracker::OnFrameSwapped only checks if they exist (and
will drop the info on the floor if they don't). It won't add them.

[sadrul, 2015-10-29 06:23:25]

On 2015/10/28 21:54:48, ccameron wrote:
> Adding sadrul@ for ui/ stamp, dcheng@ for _messages.h stamp.

lgtm

[ccameron, 2015-10-29 19:57:10]

On 2015/10/28 22:51:47, jbauman wrote:
> On 2015/10/28 22:37:05, ccameron wrote:
> >
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> > File content/browser/renderer_host/render_widget_host_view_mac.mm (left):
> > 
> >
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> > content/browser/renderer_host/render_widget_host_view_mac.mm:542:
> > latency_info.AddLatencyNumberWithTimestamp(
> > On 2015/10/28 22:27:30, jbauman wrote:
> > > Is this currently dead? If not, should these latency info components be
> added
> > > somewhere else?
> > 
> > They are added through RenderWidgetHostLatencyTracker::OnFrameSwapped ... I
> > think they were being double-added before (RWHI::FrameSwapped will re-add
them
> > ...).
> 
> RenderWidgetHostLatencyTracker::OnFrameSwapped only checks if they exist (and
> will drop the info on the floor if they don't). It won't add them.

Uah, good point. Updated this to populate the latency info in the
ImageTransportSurface in the GPU process (in the same way as is done for other
platforms).

[jbauman, 2015-10-29 20:58:36]

On 2015/10/29 19:57:10, ccameron wrote:
> On 2015/10/28 22:51:47, jbauman wrote:
> > On 2015/10/28 22:37:05, ccameron wrote:
> > >
> >
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> > > File content/browser/renderer_host/render_widget_host_view_mac.mm (left):
> > > 
> > >
> >
>
https://codereview.chromium.org/1416493010/diff/20001/content/browser/rendere...
> > > content/browser/renderer_host/render_widget_host_view_mac.mm:542:
> > > latency_info.AddLatencyNumberWithTimestamp(
> > > On 2015/10/28 22:27:30, jbauman wrote:
> > > > Is this currently dead? If not, should these latency info components be
> > added
> > > > somewhere else?
> > > 
> > > They are added through RenderWidgetHostLatencyTracker::OnFrameSwapped ...
I
> > > think they were being double-added before (RWHI::FrameSwapped will re-add
> them
> > > ...).
> > 
> > RenderWidgetHostLatencyTracker::OnFrameSwapped only checks if they exist
(and
> > will drop the info on the floor if they don't). It won't add them.
> 
> Uah, good point. Updated this to populate the latency info in the
> ImageTransportSurface in the GPU process (in the same way as is done for other
> platforms).

lgtm, sounds reasonable.

[ccameron, 2015-10-29 21:17:28]

Thanks!

[ccameron, 2015-10-29 21:17:34]

The CQ bit was checked by ccameron@chromium.org

[ccameron, 2015-10-29 21:17:34]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/1416493010/#ps40001
(title: "Update latency info")

[commit-bot: I haz the power, 2015-10-29 21:19:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1416493010/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1416493010/40001

[commit-bot: I haz the power, 2015-10-29 21:35:12]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-10-29 21:35:57]

Patchset 3 (id:??) landed as
https://crrev.com/4d4a02b8db7c319f26e823fcea22fd2b3797f538
Cr-Commit-Position: refs/heads/master@{#356956}