summaryrefslogtreecommitdiffstats
path: root/content/content_common.gypi
Commit message (Collapse)AuthorAgeFilesLines
* Support CAST+WMPI on androidhubbe2016-01-151-1/+0
| | | | | | | | | | | | | | This is a intermediate implementation of cast support for WebMediaPlayerImpl. A better long-term solution would be to implement the same functionality on top of the presentation API. As a bonus, that would work on both mobile and desktop. However, that solution may take some time to implement, and in the meantime, this CL will unblock the spitzer project. BUG=575276 Review URL: https://codereview.chromium.org/1567123002 Cr-Commit-Position: refs/heads/master@{#369869}
* Add support for "unowned" service_id to Texture.liberato2016-01-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Optionally, one may call Texture::SetUnownedServiceId() to provide a service id that will be returned for Texture::service_id(), but will not be deleted when the Texture is destroyed. The original service_id is also kept around, and will be deleted normally. Calling Texture::SetUnownedServiceId(0) will restore the original service_id. In either case, the texture is rebound to all OES_EXTERNAl units. For textures that are not OES_EXTERNAL, this call does nothing. Also updates AVDA's zero copy path to use this, to support WebGL. It creates a new texture object for the SurfaceTexture, and sets the unowned service_id for all PictureBuffer Textures to use it. BUG=540865 Review URL: https://codereview.chromium.org/1517783002 Cr-Commit-Position: refs/heads/master@{#369759}
* Add public key and signature verification to browser-side API keysiclelland2016-01-141-0/+1
| | | | | | | | | | | | | | | | This adds the ability for experimental API keys to be cryptographically verified in the browser. There is currently a single fixed signing key, whose public key is embeddded in the browser code. This makes use of Ed25519 cryptographic signature verification in boringssl, so boringssl is added as a dependency to content/common for all platforms (except iOS) BUG=543215 Review URL: https://codereview.chromium.org/1522813002 Cr-Commit-Position: refs/heads/master@{#369329}
* Implement GpuArcVideoService for arc video acceleratorkcwu2016-01-121-0/+2
| | | | | | | | | | | GpuArcVideoService creates new channel and dispatch IPC to ArcVideoAccelerator. BUG=b/25057601 Review URL: https://codereview.chromium.org/1451353002 Cr-Commit-Position: refs/heads/master@{#368797}
* Introducing SavePackageId and SaveItemId as distinct IdType<...>-based types.lukasza2016-01-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This CL: - Introduces content::IdType<...> template and unit tests. - Uses content::IdType<...> to introduce SavePackageId and SaveItemId. For now id_type.h is in content/common directory - if it proves useful for other things, then we can move it around (see also [1], [2] and [3]). [1] abandoned CL - crrev.com/1496103002: Reusing base::IdType<...> to implement SurfaceId. [2] abandoned CL - crrev.com/1492413002: Adding a compile-time safe base::IdType<...> into //base. [3] Id type discussion at chromium.org / site-isolation-dev list: https://groups.google.com/a/chromium.org/d/topic/site-isolation-dev/4YWsj6keR6s/discussion BUG=565545 Review URL: https://codereview.chromium.org/1529363006 Cr-Commit-Position: refs/heads/master@{#368502}
* Create child window in GPU process for DirectCompositionjbauman2016-01-081-0/+2
| | | | | | | | | | | | When the new --use-direct-composition command-line flag is specified the GPU process will create a new child window to present into. This will be necessary when using DirectComposition because DirectComposition can only render into windows created by the same process. The sandbox prevents the GPU process from directly doing SetParent of its child window to the browser window, so a new IPC is added to allow that. BUG=524838,545203 Review URL: https://codereview.chromium.org/1538803004 Cr-Commit-Position: refs/heads/master@{#368450}
* Add API Key parsing for experimental APIsiclelland2016-01-061-0/+2
| | | | | | | | | | | | This adds the experimental framework API key parsing mechanism to Chromium. This code deals with origins, API names, and dates. The validation currently checks for general well-formedness, and can determine, given an origin and API name, whether a given key is appropriate for use. (This is parsing only; actual signature validation is a separate CL) BUG=543146 Review URL: https://codereview.chromium.org/1521063003 Cr-Commit-Position: refs/heads/master@{#367893}
* Replace IOSurfaceManager by directly passing IOSurface Mach ports over ↵rsesek2016-01-051-2/+0
| | | | | | | | | | | | | | | | | | Chrome IPC. IOSurfaceManager was created as a mechanism to exchange IOSurfaces using Mach ports, at a time when Chrome IPC was unable to broker Mach port attachments. As part of fixing https://crbug.com/466437, Chrome IPC grew the capability to also also send Mach ports as part of a message. With this new capability, the custom Mach IPC channel used by IOSurfaceManager is no longer necessary, and its complexity can be removed. BUG=569226,323304 Review URL: https://codereview.chromium.org/1532813002 Cr-Commit-Position: refs/heads/master@{#367474}
* Revert "Share a single ServiceRegistry for all render frames in a process."rockot2015-12-161-3/+0
| | | | | | | | | | | | | | | | This reverts commit ac2a36e6cdb4739bcba077ac90950831c49b3e15. We can go back to using a per-frame ServiceRegistry because MessagePipes are cheaper now. [+ drive-by formatting of content/common/BUILD.gn] BUG=557909 TBR=jam@chromium.org Review URL: https://codereview.chromium.org/1530333002 Cr-Commit-Position: refs/heads/master@{#365638}
* PlzNavigate: Add helper method for checking if PlzNavigate is enabled.carlosk2015-12-161-3/+5
| | | | | | | | | | | | | In the interest of simplifying the code for checking if browser side navigation is enabled this change creates a new helper method and replaces all current occurrences of the "extended" form. BUG=368813 TBR=mmenke@chromium.org Review URL: https://codereview.chromium.org/1517643002 Cr-Commit-Position: refs/heads/master@{#365527}
* Create direct write font proxy classes and unit tests.kulshin2015-12-141-0/+1
| | | | | | | | | | | | | | BUG=525142 Committed: https://crrev.com/42290cb91a66566637a1715737b1961a8480b934 Cr-Commit-Position: refs/heads/master@{#363785} Committed: https://crrev.com/772bb2e55ce932909dc9ac934eabb4c47dd638d4 Cr-Commit-Position: refs/heads/master@{#364445} Review URL: https://codereview.chromium.org/1438603002 Cr-Commit-Position: refs/heads/master@{#365122}
* Hook up RendererMediaSessionManager with browser sidedavve2015-12-111-0/+1
| | | | | | | | | | | | | Implements the basic IPC messages for activation and deactivation back and forth. The browser side is still unimplemented. BUG=497735 Review URL: https://codereview.chromium.org/1441883003 Cr-Commit-Position: refs/heads/master@{#364673}
* Revert "Create direct write font proxy classes and unit tests."mek2015-12-101-1/+0
| | | | | | | | | | | | | | | | This reverts commit 772bb2e55ce932909dc9ac934eabb4c47dd638d4. This CL still causes content_unittests failures. Please make sure they are fixed before relanding.... BUG=525142 NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true TBR=kulshin@chromium.org Review URL: https://codereview.chromium.org/1514183002 Cr-Commit-Position: refs/heads/master@{#364488}
* Create direct write font proxy classes and unit tests.kulshin2015-12-101-0/+1
| | | | | | | | | | | BUG=525142 Committed: https://crrev.com/42290cb91a66566637a1715737b1961a8480b934 Cr-Commit-Position: refs/heads/master@{#363785} Review URL: https://codereview.chromium.org/1438603002 Cr-Commit-Position: refs/heads/master@{#364445}
* Revert "Create direct write font proxy classes and unit tests."Lambros Lambrou2015-12-091-1/+0
| | | | | | | | | | | | | | This reverts commit 42290cb91a66566637a1715737b1961a8480b934. Caused content_unittests to fail on Win XP/Vista bots: https://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%281%29/builds/41657 https://build.chromium.org/p/chromium.win/builders/Vista%20Tests%20%281%29/builds/62527 TBR=kulshin Review URL: https://codereview.chromium.org/1507063004 . Cr-Commit-Position: refs/heads/master@{#363852}
* Create direct write font proxy classes and unit tests.kulshin2015-12-081-0/+1
| | | | | | | | BUG=525142 Review URL: https://codereview.chromium.org/1438603002 Cr-Commit-Position: refs/heads/master@{#363785}
* content/common/gpu/media add platform suffix to some files (cleanup)mcasas2015-12-031-5/+5
| | | | | | | | | | | | | | | | | | | to make more evident which file is in which platform, plus they get automatically removed from build lists in the appropriate way. BUG= TBR=avi@chromium.org for the changes not covered by sandersd@ and posciak@ : - content/common/BUILD.gn - content/common/sandbox_mac.mm - content/gpugpu_main.cc (those are just renaming of the appropriate files). Review URL: https://codereview.chromium.org/1474823002 Cr-Commit-Position: refs/heads/master@{#363061}
* Create a field trial for Seccomp-BPF on Android.rsesek2015-11-231-0/+2
| | | | | | | | BUG=477049 Review URL: https://codereview.chromium.org/1419083012 Cr-Commit-Position: refs/heads/master@{#361136}
* Share a single ServiceRegistry for all render frames in a process.rockot2015-11-201-0/+3
| | | | | | | | | | | | | | | | | This changes ServiceRegistryImpl to implement a new content::RoutedServiceProvider mojom interface which supports normal ConnectToService as well as a ConnectToServiceRouted operation which takes a route ID for additional context. The new ConnectToServiceRouted API is then used to share ChildThreadImpl/RenderProcessHost's ServiceRegistry with each RenderFrameImpl/RenderFrameHostImpl for that process. BUG=557909 Review URL: https://codereview.chromium.org/1460803003 Cr-Commit-Position: refs/heads/master@{#360857}
* Cleanup GpuMemoryManager and helpers.sohan.jyoti2015-11-171-2/+0
| | | | | | | | | | | Now that gpu mem calculation has been moved to compositor, remove unused code. This removes GpuMemoryManagerClient and related unit tests. BUG=537563 Review URL: https://codereview.chromium.org/1420533009 Cr-Commit-Position: refs/heads/master@{#359984}
* Move Shell connection to content.ben2015-11-151-0/+1
| | | | | | | | | | | | | | | | | | I want to be able to use Mojo in content, so I think it makes sense that the shell bind step lives in content too. 1. Moves MojoRunnerState to content/common and renames it to MojoShellConnection. This class will be available in any process that creates an impl prior to running the main message loop. 2. Modifies ChildProcessLauncher to create a platform channel pair and put the client handle on the command line of the child process, and registers the server handle with the external shell. This will allow the child process to bind an Application request if it wants. TODO: What if the child process doesn't bind it? What happens to the instance created in the external shell? TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle is passed to all child processes created by content. Do we want to do this? I think it's OK for now since this code is only triggered if Chrome itself is run from within the external shell. Before we can move this to production I think CreateInstanceForHandle is going to have to take a CapabilityFilter. R=jam@chromium.org http://crbug.com/551253 Review URL: https://codereview.chromium.org/1442893002 Cr-Commit-Position: refs/heads/master@{#359770}
* Change WebRTC IP handling policy from multiple booleans to an enum.guoweis2015-11-061-0/+4
| | | | | | | | | | | | Previously in M42 we have mutliple routes as a boolean. In M47 dev, we added one more called enable_non_proxied_udp. It becomes clear that we're going to add more modes and some of the combination of booleans are not supported. We're replacing this by an enum (string in preference). To make sure we don't break the existing mutliple_routes options, a check has been put to honor that setting but multiple_routes will become readonly now and will be ignored if the new preference is set. BUG=542765 Review URL: https://codereview.chromium.org/1413393003 Cr-Commit-Position: refs/heads/master@{#358402}
* Android Webview IPC-based sync compositingboliu2015-11-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing browser-renderer call path uses SynchronousCompositorImpl to cross the logical process boundary: [BrowserViewRenderer, RenderWidgetHostViewAndroid] <-> SynchronousCompositorImpl <-> [SynchronousCompositorOutputSurface, SynchronousCompositorExternalBeginFrameSource] New call path, added behind kIPCSyncCompositing switch essentially replaces SynchronousCompositorImpl with actual IPC code. New call path looks like this: [BrowserViewRenderer, RenderWidgetHostViewAndroid] <-> SynchronousCompositorHost <-> IPC <-> SynchronousCompositorFilter <-> SynchronousCompositorProxy <-> [SynchronousCompositorOutputSurface, SynchronousCompositorExternalBeginFrameSource] Browser side: Introduce SynchronousCompositorBase which adds methods used by RWHVA. Add SynchronousCompositorHost which instead of calling to renderer directly, uses sync IPCs instead. Renderer side: Add SynchronousCompositorFilter which is responsible for filtering sync compositing messages and sending them to compositor thread. The filter doubles as the SynchronousCompositorRegistry implementation. Filter is owned by RenderThreadImpl so should outlive all other objects and the compositor thread itself. Add SynchronousCompositorProxy. This takes the place of SynchronousCompositorImpl for the single-process path; the proxy is the client for OutputSurface and BeginFrameSource. Proxy also receives sync IPC from SynchronousCompositorHost and send replies and async IPCs back. Proxy is used on the compositor thread only. Proxy lifetime is controlled by the filter (registry) and is outlived by both OutputSurface and BeginFrameSource so life time management is simple. OutputSurface and BeginFrameSource are re-used. IPCs: There are common browser and renderer states that are sent on each message from and to browser side. There is a versioning system for the renderer state since messages may arrive out of order on the browser side. BUG=526842 Review URL: https://codereview.chromium.org/1408123005 Cr-Commit-Position: refs/heads/master@{#357955}
* Vector-of-structs (instead of struct-of-vectors) in "savable resources" IPC.lukasza2015-11-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is cleaner to send a vector-of-structs rather than a struct-of-vectors (i.e. no need to verify the size of the vectors is the same, iteration is easier as it doesn't require an index to look into both vectors). This CL changes how "subframes" are sent in FrameHostMsg_SavableResourceLinksResponse. They used to be sent as 2 vectors (of URLs and of routing_ids) and now they are sent as a single vector (of a struct that contains URLs and routing_ids). The same struct (content::SavableSubframe) is reused to return results out of GetSavableResourceLinksForFrame in savable_resources.cc. The decision to reuse the same struct necessitates 1) sharing/reusing GetRoutingIdForFrameOrProxy across render_frame_impl.cc and savable_resources.cc and (so GetRoutingIdForFrameOrProxy has been moved to web_frame_utils compilation unit) 2) introducing a content::SavableSubframe struct that can be shared via A) IPC handlers in browser and renderer and B) by savable_resources.cc (and addressing B seemed better with an explicit struct with a short name, rather than introducing an implicit struct via IPC_STRUCT_BEGIN). Note that this CL keeps using a struct-of-vectors for reporting savable resources (URL + referrer). This will be addressed in a separate CL (crrev.com/1425013004). BUG=526786 Review URL: https://codereview.chromium.org/1422473004 Cr-Commit-Position: refs/heads/master@{#357852}
* Move IOSurfaceManager from content to gfx.dcastagna2015-11-011-2/+0
| | | | | | | | | | | | | | As suggested in crrev.com/1419733005 this patch moves CreateIOSurface in IOSurfaceManager and moves IOSurfaceManager from content to gfx. In this way CreateIOSurface can be reused to create IOSurfaces for GLImageIOSurface tests. BUG= Review URL: https://codereview.chromium.org/1408753003 Cr-Commit-Position: refs/heads/master@{#357290}
* Output webkit_version.h into the target_gen_dir.tfarina2015-10-271-1/+1
| | | | | | | | | | | And update callers to include it like build/util/webkit_version.h. BUG=None R=brettw@chromium.org Review URL: https://codereview.chromium.org/1418623009 Cr-Commit-Position: refs/heads/master@{#356401}
* Mac: Always use surfaceless modeccameron2015-10-271-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this change is to unify all image transport surfaces on Mac. Prior to this, if we do not support remote CoreAnimation APIs, then we will create an ImageTransportSurfaceFBO, which will send the IOSurface that it creates in the GPU process to the browser process. Change this to use the ImageTranportSurfaceOverlayMac. Using this surface will trigger the use of GpuSurfacelessBrowserCompositorOutputSurface instead of GpuBrowserCompositorOutputSurface. This output surface allocates an IOSurface-backed GpuMemoryBuffer in BufferQueue, which is rendered to. When frames are swapped in ImageTranportSurfaceOverlayMac, and remote CoreAnimation is not supported, send the backbuffer's IOSurface handle to the browser in GpuHostMsg_AcceleratedSurfaceBuffersSwapped. There is one snag here, where we are unable to open the IOSurface by its handle if the GpuMemoryBuffer that was created by BufferQueue has been destroyed. To fix this, make BufferQueue hold on to the GpuMemoryBuffer while it may be in use. Also, in GpuTransportFactory's CreateOverlayCandidateValidator, only create a validator if the remote CoreAnimation API is supported, because the non-remote-CoreAnimation path only supports drawing a single layer. BUG=546795 Review URL: https://codereview.chromium.org/1416363002 Cr-Commit-Position: refs/heads/master@{#356301}
* Move webkit_version.h.in from content to build directory.tfarina2015-10-251-1/+1
| | | | | | | | | | | This fixes the TODO in build/util/BUILD.gn BUG=None R=brettw@chromium.org Review URL: https://codereview.chromium.org/1421143003 Cr-Commit-Position: refs/heads/master@{#355992}
* ozone gbm: whitelist 3 DRM ioctl code for native GpuMemoryBuffer.dongseong.hwang2015-10-191-0/+1
| | | | | | | | BUG=475633 Review URL: https://codereview.chromium.org/1253363004 Cr-Commit-Position: refs/heads/master@{#354794}
* Added deferred rendering strategy for zero-copy AVDA.liberato2015-10-161-0/+6
| | | | | | | | | | | | | | | | | Added AndroidDeferredRenderingBackingStrategy, which doesn't copy the image into a PictureBuffer texture. Instead, it backs the PictureBuffer directly with the SurfaceTexture that the media codec decodes into. An AVDACodecImage that is attached to the PicutreBuffer's Texture asks the codec to render into the SurfaceTexture during drawing, if needed. This CL does not properly handle the transform matrix. BUG=536097 Review URL: https://codereview.chromium.org/1375073002 Cr-Commit-Position: refs/heads/master@{#354569}
* content: Use type-parameterized tests for GpuMemoryBuffer implementations.reveman2015-10-071-2/+0
| | | | | | | | | | | | This makes it easier to add type specific tests and cleans up a lot of code as a factory implementation is not longer needed for shared memory. BUG=538325 Review URL: https://codereview.chromium.org/1389133002 Cr-Commit-Position: refs/heads/master@{#352930}
* Re-land architecture for cross-process memory notification suppressingpetrcermak2015-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This patch re-lands https://codereview.chromium.org/1332583002/ after it was reverted in https://codereview.chromium.org/1359873002/ because it was causing failures on the Cast Linux buildbot. The failures were caused by std::set operations being carried out inside DCHECK macros, which are not evaluated on release builds: DCHECK(memory_message_filters_.insert(filter).second); This patch moves the std::set operations outside the macros so that they would always be evaluated: const bool success = memory_message_filters_.insert(filter).second; DCHECK(success); BUG=516776 Review URL: https://codereview.chromium.org/1361963002 Cr-Commit-Position: refs/heads/master@{#350503}
* Move WakeUpGpu logic to GpuChannelManagerpiman2015-09-241-2/+0
| | | | | | | | | | | | | | | | | | | | | We don't need to tie the WakeUpGpu to a particular surface, so instead make it a control message, and have the GpuChannelManager pick any available context. We signal GPU access on AsyncFlush instead of OnMakeCurrent, since that's both more accurate and simpler. At that point, that means renderer surfaces don't need to be ImageTransportSurfaces any more, so we can remove NullTransportSurface and ImageTransportSurfaceAndroid, we can use the default offscreen surface instead anyway. DirectSurfaceAndroid can be replaced by PassThroughImageTransportSurface directly, because it's only used to signal GPU access (which is done on AsyncFlush anyway). BUG=487471 Review URL: https://codereview.chromium.org/1366473002 Cr-Commit-Position: refs/heads/master@{#350491}
* Revert of Architecture for cross-process memory notification suppressing ↵huangs2015-09-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #11 id:240001 of https://codereview.chromium.org/1332583002/ ) Reason for revert: This seems to cause failure in Cast Linux: content_browsertests: MemoryPressureControllerBrowserTest.SetPressureNotificationsSuppressedInAllProcesses Original issue's description: > Architecture for cross-process memory notification suppressing > > This patch adds IPC architecture for suppressing memory pressure > notifications in all processes: > > BROWSER PROCESS CHILD PROCESSES > > MemoryPressureListener:: MemoryPressureListener:: > SetNotificationsSuppressed SetNotificationsSuppressed > (existing static method*) (existing static method*) > ^ ^ > | | > +--------------------------+ | > | MemoryPressureController | | > +..> | (singleton) | | > : +--------------------------+ | > : | | > : V | > : +--------------------------+ +--------------------------+ > : | MemoryMessageFilter | <===> | ChildMemoryMessageFilter | > : | (per child process) | IPC | (singleton) | > : +--------------------------+ +--------------------------+ > : > : > +.. Memory.setPressureNotificationsSuppressed > (proposed DevTools API**) > > *) The required functionality for individual processes was added in: > https://codereview.chromium.org/1312163003. > **) The new DevTools API will be added in the following 3-sided patch: > https://codereview.chromium.org/1336363002, > https://codereview.chromium.org/1311343007, and > https://codereview.chromium.org/1342833004. > > This patch adds new message filters on both sides (MemoryMessageFilter > in the browser process and ChildMemoryMessageFilter in the child > process) because we anticipate more functionality to be added to > MemoryPressureController in the near future (methods for simulating > memory pressure signals and, more importantly, propagating memory > pressure signals to all processes on desktop Chrome). Encapsulating the > relevant IPC communication in dedicated message filters is arguably > better than keeping augmenting (and having duplicate code in) > BrowserChildProcessHostImpl, RenderProcessHostImpl, and > ChildThreadImpl. > > This patch represents the second step towards implementing a DevTools > API for suppressing and simulating memory pressure signals in Chrome. > The main use case for this feature is to enforce consistent conditions > across memory measurements. See https://goo.gl/cZFdH3 for more details. > > BUG=516776 > > Committed: https://crrev.com/0b119f3392d6c6169bbb792347a04f34ce649156 > Cr-Commit-Position: refs/heads/master@{#350169} TBR=skyostil@chromium.org,primiano@chromium.org,nasko@chromium.org,chrisha@chromium.org,petrcermak@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=516776 Review URL: https://codereview.chromium.org/1359873002 Cr-Commit-Position: refs/heads/master@{#350175}
* Architecture for cross-process memory notification suppressingpetrcermak2015-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds IPC architecture for suppressing memory pressure notifications in all processes: BROWSER PROCESS CHILD PROCESSES MemoryPressureListener:: MemoryPressureListener:: SetNotificationsSuppressed SetNotificationsSuppressed (existing static method*) (existing static method*) ^ ^ | | +--------------------------+ | | MemoryPressureController | | +..> | (singleton) | | : +--------------------------+ | : | | : V | : +--------------------------+ +--------------------------+ : | MemoryMessageFilter | <===> | ChildMemoryMessageFilter | : | (per child process) | IPC | (singleton) | : +--------------------------+ +--------------------------+ : : +.. Memory.setPressureNotificationsSuppressed (proposed DevTools API**) *) The required functionality for individual processes was added in: https://codereview.chromium.org/1312163003. **) The new DevTools API will be added in the following 3-sided patch: https://codereview.chromium.org/1336363002, https://codereview.chromium.org/1311343007, and https://codereview.chromium.org/1342833004. This patch adds new message filters on both sides (MemoryMessageFilter in the browser process and ChildMemoryMessageFilter in the child process) because we anticipate more functionality to be added to MemoryPressureController in the near future (methods for simulating memory pressure signals and, more importantly, propagating memory pressure signals to all processes on desktop Chrome). Encapsulating the relevant IPC communication in dedicated message filters is arguably better than keeping augmenting (and having duplicate code in) BrowserChildProcessHostImpl, RenderProcessHostImpl, and ChildThreadImpl. This patch represents the second step towards implementing a DevTools API for suppressing and simulating memory pressure signals in Chrome. The main use case for this feature is to enforce consistent conditions across memory measurements. See https://goo.gl/cZFdH3 for more details. BUG=516776 Review URL: https://codereview.chromium.org/1332583002 Cr-Commit-Position: refs/heads/master@{#350169}
* Reland: Add accelerated VP9 decode infrastructure and an implementation for ↵posciak2015-09-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VA-API. This reverts commit 27c68f543e5eba779902447445dfb05ec3f5bf75. The CL was reverted due to a missing include on msan builder. Fixing that. Original CL description: Add accelerated VP9 decode infrastructure and an implementation for VA-API. - Add a hardware/platform-independent VP9Decoder class and related infrastructure, implementing AcceleratedVideoDecoder interface. VP9Decoder performs the initial stages of the decode process, which are to be done on host/in software, such as stream parsing and reference frame management. - Add a VP9Accelerator interface, used by the VP9Decoder to offload the remaining stages of the decode process to hardware. VP9Accelerator implementations are platform-specific. - Add the first implementation of VP9Accelerator - VaapiVP9Accelerator - and integrate it with VaapiVideoDecodeAccelerator, for devices which provide hardware VP9 acceleration through VA-API. Hook it up to the new infrastructure and VP9Decoder. - Extend Vp9Parser to provide functionality required by VP9Decoder and VP9Accelerator, including superframe parsing, handling of loop filter and segmentation initialization, state persistence across frames and resetting when needed. Also add code calculating segmentation dequants and loop filter levels. - Update vp9_parser_unittest to the new Vp9Parser interface and flow. TEST=vp9_parser_unittest,vda_unittest,Chrome VP9 playback BUG=chrome-os-partner:41469, chrome-os-partner:41470, chromium:525331 TBR=dpranke@chromium.org TBR=wuchengli@chromium.org,kcwu@chromium.org,sandersd@chromium.org,jorgelo@chromium.org,tommycli@chromium.org Review URL: https://codereview.chromium.org/1345943009 Cr-Commit-Position: refs/heads/master@{#349609}
* Revert of Add accelerated VP9 decode infrastructure and an implementation ↵tommycli2015-09-171-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for VA-API. (patchset #7 id:260001 of https://codereview.chromium.org/1318863003/ ) Reason for revert: I think this patch broke compile step for Chromium Linux ChromeOS MSan Builder. First failing build: http://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Linux%20ChromeOS%20MSan%20Builder/builds/8310 All recent builds: http://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Linux%20ChromeOS%20MSan%20Builder?numbuilds=200 Sorry for the revert. I'll re-revert if I'm wrong. Cheers, Tommy Original issue's description: > Add accelerated VP9 decode infrastructure and an implementation for VA-API. > > - Add a hardware/platform-independent VP9Decoder class and related > infrastructure, implementing AcceleratedVideoDecoder interface. VP9Decoder > performs the initial stages of the decode process, which are to be done > on host/in software, such as stream parsing and reference frame management. > > - Add a VP9Accelerator interface, used by the VP9Decoder to offload the > remaining stages of the decode process to hardware. VP9Accelerator > implementations are platform-specific. > > - Add the first implementation of VP9Accelerator - VaapiVP9Accelerator - and > integrate it with VaapiVideoDecodeAccelerator, for devices which provide > hardware VP9 acceleration through VA-API. Hook it up to the new > infrastructure and VP9Decoder. > > - Extend Vp9Parser to provide functionality required by VP9Decoder and > VP9Accelerator, including superframe parsing, handling of loop filter > and segmentation initialization, state persistence across frames and > resetting when needed. Also add code calculating segmentation dequants > and loop filter levels. > > - Update vp9_parser_unittest to the new Vp9Parser interface and flow. > > TEST=vp9_parser_unittest,vda_unittest,Chrome VP9 playback > BUG=chrome-os-partner:41469,chrome-os-partner:41470,chromium:525331 > TBR=dpranke@chromium.org > > Committed: https://crrev.com/e3cc0a661b8abfdc74f569940949bc1f336ece40 > Cr-Commit-Position: refs/heads/master@{#349312} TBR=wuchengli@chromium.org,kcwu@chromium.org,sandersd@chromium.org,jorgelo@chromium.org,posciak@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chrome-os-partner:41469,chrome-os-partner:41470,chromium:525331 Review URL: https://codereview.chromium.org/1357513002 Cr-Commit-Position: refs/heads/master@{#349443}
* Add accelerated VP9 decode infrastructure and an implementation for VA-API.posciak2015-09-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add a hardware/platform-independent VP9Decoder class and related infrastructure, implementing AcceleratedVideoDecoder interface. VP9Decoder performs the initial stages of the decode process, which are to be done on host/in software, such as stream parsing and reference frame management. - Add a VP9Accelerator interface, used by the VP9Decoder to offload the remaining stages of the decode process to hardware. VP9Accelerator implementations are platform-specific. - Add the first implementation of VP9Accelerator - VaapiVP9Accelerator - and integrate it with VaapiVideoDecodeAccelerator, for devices which provide hardware VP9 acceleration through VA-API. Hook it up to the new infrastructure and VP9Decoder. - Extend Vp9Parser to provide functionality required by VP9Decoder and VP9Accelerator, including superframe parsing, handling of loop filter and segmentation initialization, state persistence across frames and resetting when needed. Also add code calculating segmentation dequants and loop filter levels. - Update vp9_parser_unittest to the new Vp9Parser interface and flow. TEST=vp9_parser_unittest,vda_unittest,Chrome VP9 playback BUG=chrome-os-partner:41469,chrome-os-partner:41470,chromium:525331 TBR=dpranke@chromium.org Review URL: https://codereview.chromium.org/1318863003 Cr-Commit-Position: refs/heads/master@{#349312}
* Moved render_font to a common location to share with other content.forshaw2015-09-151-0/+2
| | | | | | | | | | | | | This patch moves the render_font_warmup_win files into a common location so that other content processes, especially PPAPI can share the code. This is needed as a warmup to pushing win32k lockdown to other content processes. BUG=523278 Review URL: https://codereview.chromium.org/1326623002 Cr-Commit-Position: refs/heads/master@{#348779}
* Begin refactor of AVDA to support zero-copy.liberato2015-09-141-0/+3
| | | | | | | | | | Refactor AndroidVideoDecodeAccelerator into a class that manages the MediaCodec buffers, but delegates handling the SurfaceTexture to BackingStrategy implementations. The AndroidCopyingBackingStrategy class implements the texture copy into the picture buffer, as it did in previous versions. BUG=507834 Review URL: https://codereview.chromium.org/1313913003 Cr-Commit-Position: refs/heads/master@{#348774}
* Create a RenderProcess message class and move keygen to it.avi2015-09-141-0/+1
| | | | | | | | | | | Among everything else it does, this reverts commit 5d4a2a91096ffce9d44b0850c288da6bb57bc7c6. BUG=304341 TEST=none Review URL: https://codereview.chromium.org/1345483002 Cr-Commit-Position: refs/heads/master@{#348674}
* content/gpu: Groundwork for gpu stream priorities.sunnyps2015-09-081-0/+1
| | | | | | | | | | | | | | | | | | | | This CL adds support for gpu stream priorities. A stream gets its priority when the first command buffer on that stream is created. The stream exists until the last command buffer on that stream exists. There are three priority levels: real-time, normal and low. Creating streams with real-time priority requires the gpu channel to have that capability. There's some error checking so that clients do not set an incorrect priority on an existing stream. BUG=514813 R=piman@chromium.org Review URL: https://codereview.chromium.org/1329513002 Cr-Commit-Position: refs/heads/master@{#347661}
* Add GenericSharedMemoryId and use w/ GpuMemoryBufferericrk2015-08-171-0/+2
| | | | | | | | | | | | | | | | | | | | Adds a GenericSharedMemoryId type which will be used to track various types of shared memory (SharedBitmap, IOSurface, base::SharedMemory). Wire up GpuMemoryBufferManager so that GpuMemoryBufferId is just a typedef of this type, setting up for further integration in the future. Note regarding message changes - We needed a way for all GenericSharedMemoryIds used by a process to be unique. Currently a renderer process sometimes internally allocates shared memory and sometimes asks the browser process to do so. In order to allow for consistent naming, we cause the Renderer process to provide an ID to the browser when asking the browser to allocate on its behalf. +tsepez for message changes. +piman for content/gpu changes +danakj/reveman for other changes. TBR=sky@chromium.org BUG=512534 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1280513002 Cr-Commit-Position: refs/heads/master@{#343677}
* Move Service Worker %2f path validation logic from browser into Blink (1)jeremyarcher2015-08-071-0/+2
| | | | | | | | | | | | | | | | | | This patch adds an interface by which the path validation logic can be kept in Chromium but called from within Blink. It will be eventually used to ensure that navigator.serviceWorker.register() rejects with a TypeError instead of a DOMException (see spec). 1. (Chromium) This CL. 2. (Blink) https://codereview.chromium.org/1260003003/ 3. (Chromium) https://codereview.chromium.org/1256833004/ BUG=513622 R=nhiroki,falken Review URL: https://codereview.chromium.org/1259213002 Cr-Commit-Position: refs/heads/master@{#342279}
* Get rid of FrameAccessibility using AXTreeIDsdmazzoni2015-08-071-0/+2
| | | | | | | | | | | | | | | | | | Depends on: https://codereview.chromium.org/1257093005/ Instead of keeping track of the relationship between frames in FrameAccessibility, create a subclass of AXNodeData that's only allowed to be used within the content module, and once an AX tree is received in the browser process, convert routing IDs to global AXTreeIDs that can be stored AXNodeData. BUG=368298 Review URL: https://codereview.chromium.org/1267663002 Cr-Commit-Position: refs/heads/master@{#342251}
* Plumb Blink notification actions to button UI on desktopJohn Mellor2015-08-051-0/+1
| | | | | | | | | | | | | | | | Click handling will be hooked up later. Depends on: - https://codereview.chromium.org/1263043002 - https://codereview.chromium.org/1263043003 BUG=513671 R=avi@chromium.org, palmer@chromium.org, peter@chromium.org TBR=sky@chromium.org Review URL: https://codereview.chromium.org/1267673003 . Cr-Commit-Position: refs/heads/master@{#341878}
* Fix output buffer copying in V4L2 Jpeg decode acceleratorhenryhsu2015-08-051-0/+1
| | | | | | | | | | | | | | HW JPEG decoder on some platforms have a resolution limitation. The output resolution must be a multiple of 16. The output buffer memory coping should reference hw decode coded size and output buffer size. BUG=426383 TEST=Test hw decode with resolution 424x200 and 640x360 in apprtc on peach_pi. Pass unittest. Review URL: https://codereview.chromium.org/1258213003 Cr-Commit-Position: refs/heads/master@{#341864}
* Make LatencyInfo to be classmiletus2015-08-051-1/+1
| | | | | | | | | | | | | LatencyInfo has grown to be more than a pure data holder struct. Make it a class so that we have a clean API surface that can access/modify the data members. BUG=None CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1245753003 Cr-Commit-Position: refs/heads/master@{#341831}
* ozone: unify GpuMemoryBufferFactoryOzoneNativePixmap in content/dongseong.hwang2015-07-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_pixmap.h/cc is merged into content/common/gpu/gpu_memory_buffer_factory_ozone_native_pixmap.h/cc now that that class changed name and it's not supposed to manage native "buffers" anymore but instead native "pixmaps". The reason we introduced it in the past was to avoid exposing the "pixmap" concept to content/ but as part of giving up on that we should move that code to content/. content/common/gpu/media/ already uses the "pixmap" concept. Now ui/ozone/gpu/ is not needed anymore, so remove it. Introduce GLImageOzoneNativePixmap like GLImageIOSurface and GLImageSurfaceTexture. TEST=run ozone_demo BUG=475633 Review URL: https://codereview.chromium.org/1258713002 Cr-Commit-Position: refs/heads/master@{#340927}
* Move existing kSitePerProcess checks to a policy-oracle objectnick2015-07-271-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces SiteIsolationPolicy, which interprets the kSitePerProcess switch (and eventually others too), in order to make decisions about oopifs, oopif-related features, and site isolation policy. Replace explicit calls to HasSwitch(content::kSitePerProcess) with calls to appropriate methods of SiteIsolationPolicy, BrowserPluginGuestMode, or content's browser_test_utils. SiteIsolationPolicy is content-internal, and I expect it eventually to become a stateful object. There are six cases: 1. SiteIsolationPolicy::DoesSiteRequireDedicatedProcess(url) This anticipates site isolation being launched for a subset of sites/schemes. 2. BrowserPluginGuestMode::UseCrossProcessFramesForGuests() Tracks some current feature work that requires out of process iframes and so piggybacks on --site-per-process. We ought to control this by a different flag 3. SiteIsolationPolicy::AreCrossProcessFramesPossible() For dchecks and determining whether to create proxies -- basically it is the "or" of all of the above functions. 4. SiteIsolationPolicy::UseSubframeNavigationEntries() Tracks some current feature work related to navigation, that's tied to --site- per-process. Expected to be shortlived. 5. IsSwappedOutStateForbidden() (on RFHM/RFProxy) Another class of temporary feature work. 6. content::AreAllSitesIsolatedForTesting() For bailing out of tests. BUG=481066 Review URL: https://codereview.chromium.org/1208143002 Cr-Commit-Position: refs/heads/master@{#340570}
generated by cgit v1.1 at 2025-03-28 20:44:40 +0000