summaryrefslogtreecommitdiffstats
path: root/ppapi/ppapi_proxy_untrusted.gyp
diff options
context:
space:
mode:
authorsheu@chromium.org <sheu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2014-01-28 19:09:48 +0000
committersheu@chromium.org <sheu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2014-01-28 19:09:48 +0000
commitdf77fdbf425636d51f1ad2324aed0288d7676bee (patch)
tree4a6539a8e6b8847c35aa5bea7e6f466e9a85b41c /ppapi/ppapi_proxy_untrusted.gyp
parent6c6345780aacceae1b5145bfdbeb8f5fe1e1fb1e (diff)
downloadchromium_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