New issue
Advanced search Search tips

Issue 674102 link

Starred by 2 users

Issue metadata

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



Sign in to add a comment

android_webview's SurfacesInstance should use CompositorFrameSinkSupport

Project Member Reported by fsam...@chromium.org, Dec 14 2016

Issue description

Generally, any raw usage of SurfaceFactroy should be replaced with CompositorFrameSinkSupport. android_webview/browser/surfaces_instance.cc is one such instance that should be refactored. This is in the interest of advancing the larger effort of a unified display compositor behind a mojo interface.
 

Comment 1 by boliu@chromium.org, Dec 14 2016

is the idea that at some point in the future, CompositorFrameSinkSupport will be talking to the display through a mojo interface? we probably do not want to do that in surfaces_instance
Why not? Is it a performance concern? The display compositor can still live in the same process. I was just hoping to unifying the API to the display compositor across all platforms.

Comment 3 by boliu@chromium.org, Dec 21 2016

GL has to happen on that thread, and everything has to be synchronous. I really don't see the any advantage mojo can bring here.
That's fair. I still think this bug is valid. The intention is CompositorFrameSinkSupport is the common API for CompositorFrameSinks (it does not use mojo). Clients that do cross-thread or cross-process things will use a thin mojo wrapper to CompositorFrameSinkSupport: GpuCompositorFrameSink, for example.

Even if we don't use IPC everywhere, I'd like to have a unified API to the display compositor.

Comment 5 by samans@chromium.org, Jan 18 2017

Owner: samans@chromium.org
Status: Started (was: Untriaged)
Blocking:

Comment 7 by samans@chromium.org, Jan 24 2017

Other files that use SurfaceFactory in Android:

android_webview/browser/hardware_renderer.h
ui/android/delegated_frame_host_android.cc
content/renderer/android/synchronous_compositor_frame_sink.h

Components: Internals>Compositing
Project Member

Comment 9 by bugdroid1@chromium.org, Feb 13 2017

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

commit 9eb0f5a037f216e9a0d824ebadc3b204ce479e7a
Author: samans <samans@chromium.org>
Date: Mon Feb 13 19:00:28 2017

Switching to CompositorFrameSinkSupport in android_webview::SurfacesInstance

This CL gets rid of SurfaceFactory in android_webview::SurfacesInstance
and replaces it with CompositorFrameSinkSupport. We're doing this to
unify the CompositorFrameSink API used by clients, and to simplify
transitioning to SurfaceReferences.

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

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

[modify] https://crrev.com/9eb0f5a037f216e9a0d824ebadc3b204ce479e7a/android_webview/browser/surfaces_instance.cc
[modify] https://crrev.com/9eb0f5a037f216e9a0d824ebadc3b204ce479e7a/android_webview/browser/surfaces_instance.h

Status: Fixed (was: Started)
Blocking: -601863
Components: -Internals>MUS Internals>Services>WindowService

Sign in to add a comment