Add explicit flush after copyTextureCHROMIUM to make the change visible accross contexts.

content/renderer/media/android/webmediaplayer_android.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/media/android/webmediaplayer_android.h"
 
 #include <limits>
 
 #include "base/bind.h"
 #include "base/callback_helpers.h"
@@ skipping 444 matching lines @@
   // value down to get the expected result.
   // flip_y==true means to reverse the video orientation while
   // flip_y==false means to keep the intrinsic orientation.
   web_graphics_context->pixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, flip_y);
   web_graphics_context->copyTextureCHROMIUM(GL_TEXTURE_2D, texture_id_,
                                             texture, level, internal_format,
                                             type);
   web_graphics_context->pixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, false);
   web_graphics_context->pixelStorei(GL_UNPACK_PREMULTIPLY_ALPHA_CHROMIUM,
                                     false);
-
   web_graphics_context->bindTexture(GL_TEXTURE_EXTERNAL_OES, 0);
+  web_graphics_context->flush();

[no sievers, 2014/03/18 22:54:29]

Actually, you don't need this flush either since you are using the target
context to do the copy (I believe). And the source texture will not be changed
after it was initially created (and we call glFlush() there).

[junj, 2014/03/19 07:47:37]

My understanding is that the video contents associated with the source texture
might change in the *video decoder context*, i.e. when a new video frame is
produced. The flush() here is just to make sure the *current video frame* is
copied instead of a *future video frame* being copied. That is, if no flush() is
here, the source texture might be override by new contents later and the target
context just sees the future content.

Maybe offset by one or two frames is not noticeable for video case, but just to
make the code seems more reasonable.

[no sievers, 2014/03/19 17:02:19]

The contents for the StreamTexture are actually updated to the latest on use
(when you draw with it, it happens through WillUseTexImage() called from the
decoder in, for example, DrawElements and CopyTextureCHROMIUM).

I could see maybe how it would be a little odd if somebody defined a WebGL
texture from a video element and only flushed the context much later,
effectively deferring the copy and getting a very recent frame instead of the
old one. Not sure though if the behavior is necessarily defined for this though,
I think it's all a bit vague when it comes to the spec since the video element
does not have a notion of a frame in that regard.

So seems fine to make the change in here to me then. Also to make it consistent
with WebMediaPlayerImpl::copyVideoTextureToPlatformTexture().

   return true;
 }
 
 bool WebMediaPlayerAndroid::hasSingleSecurityOrigin() const {
   if (info_loader_)
     return info_loader_->HasSingleOrigin();
   // The info loader may have failed.
   if (player_type_ == MEDIA_PLAYER_TYPE_URL)
     return false;
   return true;
@@ skipping 954 matching lines @@
 
 void WebMediaPlayerAndroid::exitFullscreen() {
   manager_->ExitFullscreen(player_id_);
 }
 
 bool WebMediaPlayerAndroid::canEnterFullscreen() const {
   return manager_->CanEnterFullscreen(frame_);
 }
 
 }  // namespace content