EVEA: Switch to MMAP memory type for MFC output buffers.

Use MMAP buffers and copy out to shared memory from them instead of passing shared memory as USERPTR to MFC. This works around corruption in output stream and the additional memcpy is in range of around a few to a few tens of kilobytes for 720p streams. This doesn't even apply to keyframes, because we were already doing a memmove of the data in their case to put the "header" in front of the dequeued stream.

The corruption happens, because the kernel keeps the USERPTR buffers it set up even after giving them back to us and tears that setup down only if we queue a different buffer than previously under given index. But the old buffer might already be in use somewhere else and the tear down may corrupt the contents in a way that we have not fully grasped yet. Contributing to this was an implicit cache sync on tearing down, but this appears not to be the only issue, as removing it didn't fix the corruption.

This should also actually improve performance. The process of queuing a USERPTR buffer includes copying vma struct for the area, pinning all pages that belong to the area (which involves laboriously walking through the page tables, pulling each page into memory from backing store if needed and incrementing refcounts on each of them), then allocating SG table for all the pages, mapping all pages in device's IOMMU, syncing the cache on noncoherent architectures and verifying contiguity of the memory. Adding to this the fact that our output buffers are 2MB in size, and that we effectively have to, in addition to do doing all the above operations, repeat them in reverse order to clean up in current implementation on each frame, a memcpy of a hundred kilobytes or so seems quite preferable. In MMAP case we only have to sync the cache (once).

As measured by hshi@:
Under Google Cast extension's High (720p) quality setting. Test page URL: Spinning WebGL Box
(www.khronos.org/registry/webgl/sdk/demos/webkit/SpiritBox.html)
Without this CL, about 18.5fps
With this CL, about 23.3fps


BUG=289775,284783
TEST=apprtc

Review URL: https://chromiumcodereview.appspot.com/23653039

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224506 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 224506
[Telemetry] Move WPR archives and credentials from src-internal to Cloud Storage.

- I uploaded the files already. They are in the bucket chrome-telemetry.
- Removed the logic that uploads page set archive info files. Those are staying in the source tree.
- Updated all references to use the new buckets. Moved the media files from chromium-wpr to chromium-telemetry.

BUG=223667
TEST=./run_benchmark netsim -v; ./run_benchmark media -v; # You should see at least two "Downloading" lines at the beginning of each run.
R=nduca@chromium.org, tonyg@chromium.org

Review URL: https://codereview.chromium.org/24294003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224507 0039d316-1c4b-4281-b951-d872f2087c98
On Mac, check the default resolution and aspect ratio to avoid distorted HD.

Re-commit of Revision 223663, which was reverted due to a code size
regression from a static initializer.

This CL introduces a heuristic that seems to avoid distorted HD on some
common consumer webcams.  The heuristic uses QTKit's default resolution
and reported pixel aspect ratio (if available) to determine whether
HD video is likely to be distorted on this capture device.

With this change, video capture begins immediately during Allocate(), but
OnFrameInfo doesn't fire until the resolution has been checked, and possibly
altered.  The camera is first opened at its default resolution.  If this is
less than HD, then HD capture is disabled.  Otherwise, if a returned HD stream
has nonsquare PAR, then HD capture is also disabled.  OnFrameInfo is only
fired once the camera has reached its final resolution.

BUG=234803

Review URL: https://chromiumcodereview.appspot.com/23929007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224508 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 224508
gpu: Upgrade DEPTH_COMPONENT16 to DEPTH_COMPONENT24 if possible

Upgrade the DEPTH_COMPONENT16 render buffer storage format to
DEPTH_COMPONENT24 if the GLES implementation supports the OES_depth24
extension. This is done to improve content portability between desktop
and mobile, since we already do a similar mapping from DEPTH_COMPONENT16
to the unsized DEPTH_COMPONENT on desktop GL. This means that for
example WebGL content can end up relying on a higher precision depth
buffer even though it only requested DEPTH_COMPONENT16.

BUG=285400
TEST=http://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html on Nexus 4

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=224117

Review URL: https://chromiumcodereview.appspot.com/24079010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224509 0039d316-1c4b-4281-b951-d872f2087c98
Added task runner test to be able to fake the time better.

BUG=

Review URL: https://chromiumcodereview.appspot.com/24216004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224510 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 224509
SVN changes up to revision 224510
Implement clearView to match classic

Note that it needs a separate CL downstream to actually call this

NOTRY=true

Review URL: https://chromiumcodereview.appspot.com/22849016

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224511 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 224511