diff options
author | sheu@chromium.org <sheu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-01-28 19:09:48 +0000 |
---|---|---|
committer | sheu@chromium.org <sheu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-01-28 19:09:48 +0000 |
commit | df77fdbf425636d51f1ad2324aed0288d7676bee (patch) | |
tree | 4a6539a8e6b8847c35aa5bea7e6f466e9a85b41c /ppapi/ppapi_proxy_untrusted.gyp | |
parent | 6c6345780aacceae1b5145bfdbeb8f5fe1e1fb1e (diff) | |
download | chromium_src-df77fdbf425636d51f1ad2324aed0288d7676bee.zip chromium_src-df77fdbf425636d51f1ad2324aed0288d7676bee.tar.gz chromium_src-df77fdbf425636d51f1ad2324aed0288d7676bee.tar.bz2 |
This change removes all the threading considerations from
GpuVideoAcceleratorFactories (and its implementation,
RendererGpuVideoAcceleratorFactories). Most notably, it removes Abort() and
associated functions and state. And with the removal of Abort() and friends,
we can also remove its Clone() interface.
All of the previously abortable operations on the RGVAF (with the exception of
ReadPixels()) can be made non-abortable, with no functional difference, due to
the way the users of RGVAF function. These three users are
WebMediaPlayerImpl/GpuVideoDecoder, RTCVideoDecoder, and RTCVideoEncoder, and
they can be made non-abortable because:
WebMediaPlayerImpl/GpuVideoDecoder:
* Abort() is called from WebMediaPlayerImpl::Destroy(). It has no effect, as:
* All the RGVAF entry points are called from the the RGVAF message loop
from GpuVideoDecoder (except for ReadPixels()), so the Abort() has no
effect on them.
RTCVideoDecoder:
* Abort() is called from RTCVideoDecoder::WillDestroyCurrentMessageLoop() for
the RGVAF message loop. It has no effect, as:
* Amost all the RGVAF entry points are called from the RGVAF message loop
(except for ReadPixels()), so Abort() has no effect on them.
* The other exception is CreateVideoDecodeAccelerator(), which is called from
RTC's main thread. But as the Abort() is called from
WillDestroyCurrentMessageLoop() for the RGVAF message loop itself, it is
guaranteed to occur after any tasks posted to the RGVAF message loop by
CreateVideoDecodeAccelerator() has completed, and so the Abort() has no
effect.
RTCVideoEncoder:
* Abort() is called from RTCVideoDecoder::Release(). It has no effect, as:
* All the RGVAF entry points are called from the RGVAF message loop.
The only functional difference remaining is that making ReadPixels()
non-abortable. This is preferable, as as long as a completed video accelerator
texture is available, it should be readable. We also specify that all calls to
ReadPixels must be made on the RGVAF message loop, like all other entry points,
and leave it up to the users of ReadPixels() to handle thread trampolining if
necessary.
BUG=306333
TEST=local build, run on CrOS snow; build, run unittests on desktop Linux
Review URL: https://codereview.chromium.org/27420004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247480 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'ppapi/ppapi_proxy_untrusted.gyp')
0 files changed, 0 insertions, 0 deletions