Removes `#include "base/macros.h"` from remaining .cc, .h and .mm files
that do not contain `ignore_result(` and do not trigger pre-commit or
pre-upload errors.
Bug: 1010217
No-Try: true
Change-Id: I4cc5207b3deafa7901764d2e633bbb1ad43cfb73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276692
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941054}
This replaces DISALLOW_COPY_AND_ASSIGN with explicit constructor deletes
where a local script is able to detect its insertion place (~Foo() is
public => insert before this line).
This is incomplete as not all classes have a public ~Foo() declared, so
not all DISALLOW_COPY_AND_ASSIGN occurrences are replaced.
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: Iab44b67c7ca86cf5cfb1f6b27de5c18769d36632
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3177680
Auto-Submit: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#924479}
Use an UnsafeSharedMemoryRegion instead of the existing handle. The
shared memory on the host side is used read-only, but because a
writable region needs to be shipped to the other side of the proxy, an
unsafe region needs to be used.
Host | Other side of proxy
-----------------------------+---------------------------------
| Request SHM
Create SHM <-----------------------/
Reply with SHM Handle |
| \-------------------------> Receive SHM
Save SHM by ID |
|
| Fill SHM with video to decode
| (write to SHM)
| Send SHM ID to Host
Receive decode request <-----------/
Look up buffer by ID |
Decode what's in the SHM |
(read-only SHM access)
The host-side could use a read-only region only by adding an additional
round-trip, with the other side of the proxy either converting to
read-only after mapping writable, and shipping back to the host,
or the other side of the proxy mapping, shipping back a writable
handle, and then the host converting to read-only. This has not been
done in this CL.
Bug: 849207
Change-Id: I3e50f9ff9c65e51c21c7e4d72b3aed2402c03196
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1615021
Commit-Queue: Matthew Cary (CET) <mattcary@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#666194}
base::hash_map is alias of std::unordered_map now.
I applied following command to make this CL.
$ git grep -l 'base::hash_map' | fgrep -v base/ | xargs sed -i -e 's/base::hash_map/std::unordered_set/g' -e 's/\(#include <[a-z_]*>\)/\1\n#include <unordered_map>/' -e 's/BASE_HASH_NAMESPACE/std/'
$ git cl format
$ # Added IntPairHash and replaced BASE_HASH_NAMESPACE with std in some places.
TBR: dcheng@chromium.org
Bug: 576864
Change-Id: I38941d9f9bcb05ec474b8dee5230c4c5dcd2211f
Reviewed-on: https://chromium-review.googlesource.com/c/1390892
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620124}
For obscure historical reasons, mailbox names were created on the
renderer side whereas the textures are produced on the plugin side. Move
the mailbox name creation to the plugin side so that it happens when the
textures are produced. A follow-up will merge the 2 operations.
Bug: 847674
Change-Id: Ia8cde57c2c0421e1361ddb14de63f02a34ea9b6f
Reviewed-on: https://chromium-review.googlesource.com/1081669
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563858}
We are standardizing on the base implementation whenever possible.
Updates typedefs to using statements when code was changed.
file_transfer_message_handler_unittest.cc got a new helper function
since base::queue lacks an operator== required for gtest.
Bug: 757232
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I98d0c6880a5fcf5d236634abca51ba0fe41eeb6c
Reviewed-on: https://chromium-review.googlesource.com/682755
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504191}
Remove useless class and struct forward declarations, and add
missing ones in ppapi header files.
BUG=662195
Review-Url: https://codereview.chromium.org/2539033005
Cr-Commit-Position: refs/heads/master@{#436167}
When using the video decoder PPAPI, the most recent version of the ARC extension requires there to be a certain minimum number of picture buffers in flight (allocated but not released). Without a larger pool, ARC video decoding will stall trying to allocate more decoded picture frames than are available by default.
This patch creates a new DEV interface version for the VideoDecoder PPAPI. The new interface simply adds a single new argument to VideoDecoder::Initialize() so that a PPAPI client indicate the minimum number of pictures it needs to function.
In order to implement this minium picture count, the meaning of the ProvidePictureBuffers() interface call used by the video decoder implementations has changed slightly. After making the call to ProvidePictureBuffers() with a given picture buffer size, the subsequent callback via AssignPictureBuffers() includes a std::vector of buffers that might be larger than requested.
I've adjusted the various implementations to handle this change -- most of them previously assumed and asserted that the count was the same.
In particular this meant moving some code around in the V4L2 implementations since they also do some internal allocations based on the number of picture buffers that actually end up being chosen.
BUG=485775
Review URL: https://codereview.chromium.org/1207043002
Cr-Commit-Position: refs/heads/master@{#344391}
The Google style guide states that only one of {virtual,override,final} should be used for each declaration, since override implies virtual and final implies both virtual and override.
This patch was manually generated using a regex and a text editor.
BUG=417463
Review URL: https://codereview.chromium.org/1097393007
Cr-Commit-Position: refs/heads/master@{#326505}
Add 'Initialize' method that takes an enum value to specify hardware
acceleration policy. Policies are always, with fallback and only software.
BUG=406194
Review URL: https://codereview.chromium.org/496203002
Cr-Commit-Position: refs/heads/master@{#291606}
Reason for revert:
Broke blink Linux tests compile.http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests/builds/37259
Original issue's description:
> Implement software fallback for PPB_VideoDecoder.
> This modifies the proxy to implement software fallback mode.
> The main change is to the host, which now can work with
> media::VideoDecoders.
>
> media::VideoDecoder works differently from media::VideoDecodeAccelerator
> so an adapter object, content::VideoDecoderShim is defined. It lives on the main thread and drives the actual decoder on the media thread via a child DecoderImpl class, which sends back frames of video. VideoDecoderShim receives those and converts frames to GL textures.
>
> gpu::Mailboxes are used so the host can create textures that are aliased
> to the plugin's textures.
>
> The test plugin has been changed to include bitstream data for VP8 in order to
> test the software decoder. The data is in ppapi/examples/video_decode/testdata.h
> alongside the H264 data. The file diff is too large for this site but is structured
> something like this:
>
> const unsigned char kData[] = {
> #if defined USE_VP8_TESTDATA_INSTEAD_OF_H264
> ... lots of VP8 data
>
> #else // !USE_VP8_TESTDATA_INSTEAD_OF_H264
> ... lots of H264 data
>
> #endif // USE_VP8_TESTDATA_INSTEAD_OF_H264
> };
>
>
> There is a TODO to convert the example to load a file. I'm not sure how to go
> about that but am willing to do the work if someone can point the way.
>
> BUG=281689
> R=dmichael@chromium.org, fischman@chromium.org, sievers@chromium.org, tsepez@chromium.org
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=277012TBR=dmichael@chromium.org,fischman@chromium.org,igorc@chromium.org,piman@chromium.org,sievers@chromium.org,tsepez@chromium.org,bbudge@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=281689
Review URL: https://codereview.chromium.org/337683002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@277015 0039d316-1c4b-4281-b951-d872f2087c98
This modifies the proxy to implement software fallback mode.
The main change is to the host, which now can work with
media::VideoDecoders.
media::VideoDecoder works differently from media::VideoDecodeAccelerator
so an adapter object, content::VideoDecoderShim is defined. It lives on the main thread and drives the actual decoder on the media thread via a child DecoderImpl class, which sends back frames of video. VideoDecoderShim receives those and converts frames to GL textures.
gpu::Mailboxes are used so the host can create textures that are aliased
to the plugin's textures.
The test plugin has been changed to include bitstream data for VP8 in order to
test the software decoder. The data is in ppapi/examples/video_decode/testdata.h
alongside the H264 data. The file diff is too large for this site but is structured
something like this:
const unsigned char kData[] = {
#if defined USE_VP8_TESTDATA_INSTEAD_OF_H264
... lots of VP8 data
#else // !USE_VP8_TESTDATA_INSTEAD_OF_H264
... lots of H264 data
#endif // USE_VP8_TESTDATA_INSTEAD_OF_H264
};
There is a TODO to convert the example to load a file. I'm not sure how to go
about that but am willing to do the work if someone can point the way.
BUG=281689
R=dmichael@chromium.org, fischman@chromium.org, sievers@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/311853005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@277012 0039d316-1c4b-4281-b951-d872f2087c98
