Add support for EXT_image_flush_external extension

ui/gl/gl_image.h

Index: ui/gl/gl_image.h
diff --git a/ui/gl/gl_image.h b/ui/gl/gl_image.h
index 8a7a21203f9404196d8a10caae8afc27ca042ae5..bb2cd5ddcd7c04fb996ef95827fce7f4f2ec5c80 100644
--- a/ui/gl/gl_image.h
+++ b/ui/gl/gl_image.h
@@ -92,6 +92,9 @@ class GL_EXPORT GLImage : public base::RefCounted<GLImage> {
   };
   virtual Type GetType() const;
 
+  // Flush any preceding rendering for the image.
+  virtual void Flush() = 0;

[reveman, 2016/06/29 07:37:51]

Do we need to add GLImage API function for this? It looks like it's only used
for overlay scheduling. Can we handle this as part of the
GLImage::ScheduleOverlayPlane implementation instead?

[vinceh, 2016/06/29 07:44:36]

That's actually implemented according to Daniel's suggestion if I understood his
words correctly. Daniel, any comments?

[dnicoara, 2016/06/29 14:21:56]

My thought was to make it a generic API since it is implemented as an EGLImage
extension (and not couple overlay scheduling with image flushing). But perhaps
this is overly generalizing (especially since it is changing quite a bit of
files)?

[vinceh, 2016/06/30 09:22:48]

Then let's implement this inside GLImageOzoneNativePixmap::ScheduleOverlayPlane,
OK?

[marcheu1, 2016/07/01 06:45:58]

If we do this as part of ScheduleOverlayPlane, wouldn't we have to return a
fence that the async swap can use? If so that seems as complicated to me as
implementing a new entry point for images...

[reveman, 2016/07/11 18:59:06]

Is this flush needed in the sw raster case? In the arc++ case, it's not, as
we're using explicit synchronization and I think this might result in a
significant performance regression. 

+
  protected:
   virtual ~GLImage() {}