Revert of Revert of Remove threading from RendererGpuVideoAcceleratorFactories...
Revert of Revert of Remove threading from RendererGpuVideoAcceleratorFactories (https://codereview.chromium.org/145103004/) Reason for revert: Reverting the revert as it did not fix the failures. Original issue's description: > Revert of Remove threading from RendererGpuVideoAcceleratorFactories (https://codereview.chromium.org/27420004/) > > Reason for revert: > Sorry, it looks like you broke the Win 7 Tests (dbg)(2) bot. http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%282%29/builds/19785 > > Original issue's description: > > 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 > > > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247480 > > TBR=fischman@chromium.org,wuchengli@chromium.org,jamesr@chromium.org,jam@chromium.org,hshi@chromium.org,sheu@chromium.org > NOTREECHECKS=true > NOTRY=true > BUG=306333 > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247655 TBR=fischman@chromium.org,wuchengli@chromium.org,jamesr@chromium.org,jam@chromium.org,hshi@chromium.org,sheu@chromium.org NOTREECHECKS=true NOTRY=true BUG=306333 Review URL: https://codereview.chromium.org/135393004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247662 0039d316-1c4b-4281-b951-d872f2087c98
Showing
Please register or sign in to comment