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

content/renderer/media/android/webmediaplayer_android.cc

Index: content/renderer/media/android/webmediaplayer_android.cc
diff --git a/content/renderer/media/android/webmediaplayer_android.cc b/content/renderer/media/android/webmediaplayer_android.cc
index c184afcd91d9fae451bbb3c0a102bbfdbd4b45fa..c80c72ccacd8c6de4e0090602351467d3630f893 100644
--- a/content/renderer/media/android/webmediaplayer_android.cc
+++ b/content/renderer/media/android/webmediaplayer_android.cc
@@ -462,8 +462,8 @@ bool WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
   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;
 }