This creates a new embedder delegate that allows the embedder to modify
the GrContextOptions passed to skia. Behind a flag that is disabled by
default, this CL disables mip map sharpening and sets MSAA sample count
to 0.
Bug: 364872963
Change-Id: Ifec3c530d0a9bf837b313b01ed7c41094446e483
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5982515
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Alex Mitra <alexmitra@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389835}
These methods are present only for Android WebView. By making them
Android-only, we make it more clear that it is not possible on other
platforms for the respective dependencies to be created externally to
Viz itself.
Change-Id: Ia4ac7854245451e8ff98ff46c836445c00468242
Bug: 330865436
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5991439
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1378273}
This is a refactor that does not intend to change behavior, but prepares
for fixing logic for deleting shader cache if shader loading fails.
Motivation is making ActivityFlags since there can be multiple GPU
threads that load shaders now. ActivityFlags has only ever had one
flag since its inception years ago. So just remove the support for
multiple flags and just turn it into a count that's incremented
atomically. Switch to using std::atomic since base::subtle::Atomics
is deprecated.
Rename everything from "activity flags" to "use shader cache shm
count".
Bug: 1470074
Change-Id: Ie77b6d347e86402ecff8891d600efd36e49d0418
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4762849
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184321}
communication between UkmRecorder<->MojoUkmRecorder.
Add UkmRecorderFactory mojo interface and implementation to allow
sending updates to UkmRecorderParameters when kUkmReduceAddEntryIPC
experiment is enabled along with allowing MojoUkmRecorder to send
information to UkmRecorder. |client_remote| argument in
CreateUkmRecorder method of UkmRecorderFactory is optional.
Bug: b/261857368, b/275542357
Change-Id: I7a3a17560474cb93a945f0a3381abd22d33f06c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4334311
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Aman Verma <amanvr@google.com>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Carlos Caballero Grolimund <carlscab@google.com>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1125695}
Most of the files touched are for plumbing to so that the same
gpu::Scheduler instance is accessible on both render thread and
gpu thread.
Add a scoped struct in gpu::Scheduler to raise priority of a
sequence. And use it in TaskForwardingSequence::RunTask if it
ends up waiting on a sync token.
Also remove unused DeferredGpuCommandService.
Bug: 1353805
Change-Id: I26ea2c6b77de6fda548269ac745d2a73b10a2c6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3843038
Commit-Queue: Bo Liu <boliu@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1039482}
Why: It's a combination of 2 things:
* ChromeOS is beginning to use Skottie for some of its animations.
The animation may contain text embedded in it, in addition to
specifying the font for said text.
* ChromeOS uses OOP (out-of-process) raster, meaning all raster
operations happen in the GPU process. More specifically in this
case, a skottie animation object is instantiated in the GPU
process and we call skottie::Animation::render() in it. As such,
the GPU process must somehow have access to the font cache, or
Skottie fails to load the appropriate font typeface when rendering.
This follows the exact same pattern as what's done in the render
process (see renderer_blink_platform_impl.cc) and utility process by
connecting to the font service that's hosted in the browser process.
Bug: b:217271404
Cq-Include-Trybots: luci.chrome.try:linux-chromeos-chrome
Change-Id: I4d6dfd1d96f8e412a21c71c0391401848efd4da3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3464510
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Eric Sum <esum@google.com>
Cr-Commit-Position: refs/heads/main@{#972745}
VaapiVideoDecoder on linux requires Vulkan > 21.1.5, and so requires
a check for this when deciding whether HW video decoding is supported.
Bug: 1236697
Change-Id: I1306dbb0c3fd72f534b33610f1777d59faebffcf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3230232
Commit-Queue: Ted Meyer <tmathmeyer@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#943789}
This CL was generated by using tools/git/move_source_file.py to change
the includes for those files:
base/bind_post_task.h
base/deferred_sequenced_task_runner.h
base/post_task_and_reply_with_result_internal.h
base/sequenced_task_runner.h
base/sequenced_task_runner_helpers.h
base/single_thread_task_runner.h
base/task_runner.h
base/task_runner_util.h
base/updateable_sequenced_task_runner.h
Then formatted using "git cl format". DEPS files were fixed with a
simple search and replace script.
Bug: 1255932
Change-Id: I0d9b5ddd9260fde5e4581e6c6e0080bdb0ed2c44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3209175
Reviewed-by: Gabriel Charette <gab@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#929867}
This reverts commit 6dc0acff58.
Reason for revert: Still breaks some GPU integration tests on Mac ASAN, probably timing issues.
Original change's description:
> Remove primordial IPC Channel from GPU processes
>
> GPU processes do not use this for anything other than monitoring process
> lifetime, implicitly through generic ChildProcessHostImpl and
> ChildThreadImpl behavior. Since these objects are now capable of
> coordinating process lifetime without a legacy IPC Channel present, the
> Channel does not need to exist at all for GPU processes. This CL removes
> it.
>
> Bug: 1196476
> Change-Id: Id4e5231303572f85c37048b58e3f7dbe791d4782
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2986000
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Commit-Queue: Ken Rockot <rockot@google.com>
> Cr-Commit-Position: refs/heads/master@{#895924}
Bug: 1196476
Change-Id: I36ba8bd735035b2c0a83e5731ed3dfdd76d9cb6d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2988012
Auto-Submit: Ken Rockot <rockot@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Andy Paicu <andypaicu@chromium.org>
Owners-Override: Andy Paicu <andypaicu@google.com>
Cr-Commit-Position: refs/heads/master@{#896034}
GPU processes do not use this for anything other than monitoring process
lifetime, implicitly through generic ChildProcessHostImpl and
ChildThreadImpl behavior. Since these objects are now capable of
coordinating process lifetime without a legacy IPC Channel present, the
Channel does not need to exist at all for GPU processes. This CL removes
it.
Bug: 1196476
Change-Id: Id4e5231303572f85c37048b58e3f7dbe791d4782
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2986000
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#895924}
This is a reland of 51c5fcb851
which just removes the unused APIs and omits the the change to
IPC Channel initialization for GPU processes. That change needs
to be investigated further due to subtle breaking side effects
around GpuProcessHost lifetime and/or related events in the
browser.
Original change's description:
> Remove unused legacy IPC APIs from GPU & Utility processes
>
> GPU and Utility processes no longer use any legacy IPCs. This removes
> their process hosts' implementation of IPC::Sender and IPC::Listener
> interfaces, as well as from GpuChildThread.
>
> This also omits initialization of the main legacy IPC Channel for
> GPU processes, as it's no longer used.
>
> Bug: 993189, 1196476
> Change-Id: Ie0e74d09ef1b6bbcd4ebbc2d482dcaebb79481b4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2967049
> Commit-Queue: Ken Rockot <rockot@google.com>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#893274}
Bug: 993189, 1196476
Change-Id: I3c1fe87ecd7e6e9a8d8ee768af4167571e66c5c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2970603
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#893591}
This reverts commit 51c5fcb851.
Reason for revert: Mac FYI GPU ASAN Release seems to consistly fails likely caused by low power gpu not used. Try reverting this one since it's the only gpu change in the blamelist
Original change's description:
> Remove unused legacy IPC APIs from GPU & Utility processes
>
> GPU and Utility processes no longer use any legacy IPCs. This removes
> their process hosts' implementation of IPC::Sender and IPC::Listener
> interfaces, as well as from GpuChildThread.
>
> This also omits initialization of the main legacy IPC Channel for
> GPU processes, as it's no longer used.
>
> Bug: 993189, 1196476
> Change-Id: Ie0e74d09ef1b6bbcd4ebbc2d482dcaebb79481b4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2967049
> Commit-Queue: Ken Rockot <rockot@google.com>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#893274}
Bug: 993189, 1196476, 1221227
Change-Id: Iab2062d99bf6f2c6ce13380709228937e2d32d6f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2969707
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Shrek Shao <shrekshao@google.com>
Reviewed-by: Ken Rockot <rockot@google.com>
Owners-Override: Shrek Shao <shrekshao@google.com>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Cr-Commit-Position: refs/heads/master@{#893534}
GPU and Utility processes no longer use any legacy IPCs. This removes
their process hosts' implementation of IPC::Sender and IPC::Listener
interfaces, as well as from GpuChildThread.
This also omits initialization of the main legacy IPC Channel for
GPU processes, as it's no longer used.
Bug: 993189, 1196476
Change-Id: Ie0e74d09ef1b6bbcd4ebbc2d482dcaebb79481b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2967049
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893274}
VizMain is bound in the GPU process as an interface associated with the
main legacy IPC Channel. That Channel is no longer used for any other
purpose though, so the association serves no purpose. The only legacy
IPC Channels in use by the GPU process are created later, as an
implementation detail of Viz (via EstablishGpuChannel IPCs).
This changes the VizMain interface to use a regular interface pipe
instead of an associated interface.
Bug: None
Change-Id: Id6b3b6352f7d2327ab5c9808893155f2d5ce445a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2806255
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Auto-Submit: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#869760}
This change:
- adds GpuServiceImpl::SetVisibilityChangedCallback() method
to register a callback;
- updates GpuServiceImpl::OnBackgrounded/OnForegrounded to run
the callback on the main thread;
- registers the callback in it GpuChildThread::OnGpuServiceConnection
for an out-of-process GPU service.
This will only work on Android since OnBackgrounded/OnForegrounded is
only called there.
Bug: 1177542
Change-Id: Ia11ff91726f986ad46519a3299fd7e7c12f93dc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2717340
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Commit-Queue: Oksana Zhuravlova <oksamyt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#859110}
The GPU process mojo error handler would cache the error string for 5
seconds and if a specific crash was triggered the error string would be
put in a crash key. This produced some unexpected error strings, see
https://crbug.com/1075495#c32, for deserialization errors on
viz.mojom.CompositorFrameSink interface between browser and GPU.
Change the error handler to immediately DumpWithoutCrashing() so we get
a stack trace during deserialization. Hopefully the stack trace will
provide some better clues as to what went wrong.
Bug: 1075495
Change-Id: Iaa9d6c0cddb43132603c5c0fffc1e9a76c745631
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2405413
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#806878}
When the exit_on_context_lost workaround is enabled, the GPU process is
terminated when a context lost occurs. This CL causes the termination
to return an error code rather than a normal exit code.
In addition, a normal termination of the GPU process should not block
the domain for WebGL. GpuProcessHost currently blocks WebGL for normal
termination except on Android because terminating for context lost
previously registered as a normal termination. Now that exiting for
context lost is no longer registered as a normal termination, we can
prevent WebGL from being blocked for normal terminations.
Bug: 598400
Change-Id: Ib912f5f905db0d622e8e561a3202d1630ee20afb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2140773
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Patrick To <patrto@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#767923}
OzoneDrmMojo is 100% on. This is 2nd CL to remove more Legacy IPC code in ozone.
Another CL(3/3) will remove ui/ozone/common/gpu/ozone_gpu_message_params.h and related files.
Bug: 620927,806092
Change-Id: Id5cdca9f98677a617a551999d89864f10b753115
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2167765
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kramer Ge <fangzhoug@chromium.org>
Cr-Commit-Position: refs/heads/master@{#763571}
Prior to this change there exists a window between when GpuMain()
hands off log collection and when GpuServiceImpl::InitializeWithHost()
starts forwarding to the GpuProcessHost. We have sometimes lost key
debugging logs in these cases.
Now GpuServiceImpl handles collection of GpuMain() logs all the way up
until GpuServiceImpl::InitializeWithHost() takes over, so no logs are
lost during startup.
Fixed: 1065082
Change-Id: I1d0376ca917218cb6cb6c7298ad59021ba6832ad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2123329
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#754614}
When running the GPU process, we use dependency injection to customize
its behaviour through the ExternalDependencies struct. VizMainImpl's
constructor takes an ExternalDependencies parameter and std::moves it to
a member field. Some of the code, however, continued to reference the
parameter instead of the field. This lead to the code assuming that some
dependencies were stubbed out.
This CL updates VizMainImpl's constructor to consistently check the
member field for the injected values and adds tests to check that some
injected values end up in use.
Bug: 1040583
Change-Id: If1c7922f4c7286c2a73afd33572b287ad29f64ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1992701
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Tom McKee <tommckee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#733385}
Recent refactorings have allowed some service interfaces to be bound
in the GPU process before the GPU process is fully initialized. In some
cases this can cause crashes due to use of an uninitialized
GpuServiceFactory instance.
This restores the intended queueing behavior for service interface
binding requests so that their processing is deferred until full GPU
initialization.
Fixed: 1034746
Change-Id: I33e39ca71c977772cdd08a2f8b96b18d9c0e836c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1972456
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#725817}
This removes dependencies on Service Manager from the Media Service
implementation and public API. The service already had a main
MediaService interface used by the browser, so this just exposes that
directly from a content::GetMediaService() helper API rather than
requiring clients to go through a Service Manager Connector.
This preserves the behavior where the Media Service instance may run
in either the GPU process, the browser process, or a standalone service
process depending on a GN arg value. The logic around this is now
centralized within the content::GetMediaService() implementation.
This also replaces the "media_renderer" service with a slightly less
obscure mechanism -- content::MediaInterfaceProxy will ask the Content
client to create a secondary in-process-only instance of the Media
Service if possible. If created, MediaInterfaceProxy will use the
secondary instance in all the same scenarios where "media_renderer" was
used before. This is functionally equivalent to the behavior before
this change.
Bug: 977637
Change-Id: Ib29ff575f718444032334a1fee8300be7a62528d
Tbr: alexclarke@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1944629
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kenneth MacKay <kmackay@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#724392}
Do it in an atomic way rather than cleanly releasing resources, etc.
The latter has been the source of many hangs and crashes. It's not
worth the efforts.
When browser process exits, I believe we already shuts down GPU
process atomically.
After this change, the only clean exit for GPU process is the
unsandboxed GPU process that is to collect extra GPU information.
It needs to shut down cleanly to make sure the info collected
has been received by browser process.
BUG=896565,1018233,1027137
TEST=manual
R=kbr@chromium.org,sunnyps@chromium.org
Change-Id: I082a06945d261db0fb9a4549859adf1e057212ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1949671
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#721319}
This changes the GPU process to expose browser-facing interfaces through
the Content ChildProcess interface.
ChildThreadImpl now allows subclasses to provide a BinderMap to handle
incoming interface binding requests from the browser. This is a fairly
simple drop-in replacement for what used to be done through
the Service Manager with a ConnectionFilter.
There should be no behavioral changes here. In particular for
GPU interfaces, this CL is careful to preserve the behavior which avoids
binding incoming interface receivers until |OnGpuServiceConnection()| is
invoked.
Bug: 977637
Change-Id: Id00a1f0b1178f9c3fed2816eea9808f162829798
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1905050
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#714969}
With the Service Manager going away, the manifest files that previously
mediated access to Mojo services across processes are going away too.
Under the new system, various //content classes have methods that bind
mojo::Receiver<T> objects via GenericPendingReceiver. Since these call
sites control access to objects across a privilege boundary, they should
be under the SECURITY_OWNERS review system.
This first pass splits out several //content and //chrome ones, but
more to come.
Bug: 1012033
Change-Id: Ic09c825c8503c570393fa7ce4d89b58bb6efe391
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1848416
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706219}
This removes the usage of Ozone directly in PlatformVideoFramePool via
the associated util file. This will allow for unit testing of more
code since the whole Ozone dependency will not be dragged into this code
and we can mock out the GpuMemoryBufferFactory instead.
Bug: 1007487
Test: Unit tests, video_decode_accelerator_test --use_vd,
video_encode_accelerator_unittest and image_processor_test (same results
as ToT for both), YT playback on nocturne
Change-Id: Iabed106319ace56096a34189b9c8986a03d80653
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1827888
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Jeffrey Kardatzke <jkardatzke@google.com>
Cr-Commit-Position: refs/heads/master@{#703849}
This removes almost all remaining usage of Connector from child
processes, instead preferring use of ChildProcessHost.BindHostReceiver
to acquire process-scoped interfaces from the browser.
The one remaining use case after this CL is for the Device Service's
PowerMonitor API. This is left as a separate change because it requires
substantial additional support code for testing.
Bug: 977637
Change-Id: I679c6d7f5ec01d1bc1bb6852e0f79a3f1650df34
Tbr: penghuang@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1815731
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#700317}
This service is run in the GPU process and its interfaces are bound only
by the browser, brokering unfiltered requests from renderers. Logic is
simplified by removing all dependencies on Service Manager APIs, in
favor of the browser's brokering logic talking directly to
GpuProcessHost and maintaining a persistent connection to the service.
Bug: 977637
Change-Id: I9047889de659b8ff61df4bae40867d3b81d8127f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1761689
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#688616}
Make VizCompositorThreadRunner into an abstract interface and move the
existing implementation to VizCompositorThreadRunnerImpl. Then add
VizCompositorThreadRunnerWebView which will be webview's entry point
into creating and establishing viz objects.
Add code paths to ContentGpuClient so that webview can optionally
override the default instance.
Currently VizCompositorThreadRunnerWebView doesn't do much, except it
uses TaskQueueViz and exposes a simple API to run and block for work on
viz while allowing viz to schedule tasks on the render thread.
Bug: 805739
Change-Id: Ic5d2c45666ebc1fc9381c8cd5c71b0de57dd0136
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1731135
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683768}
