Add support for ES3 MSAA.

include/gpu/gl/GrGLConfig.h

 
 /*
  * Copyright 2011 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 
 
@@ skipping 152 matching lines @@
 #endif
 
 #if !defined(GR_GL_MUST_USE_VBO)
     #define GR_GL_MUST_USE_VBO                          0
 #endif
 
 #if !defined(GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE)
     #define GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE       0
 #endif
 
+// We now have a separate GrGLInterface function pointer entry for the IMG/EXT version of
+// glRenderbufferStorageMultisampled. However, Chrome is setting the one we now use for
+// ES3 MSAA to point to the IMG/EXT function. This macro exists to make Skia ignore the
+// ES3 MSAA and instead use the IMG/EXT version with the old function pointer entry. It will
+// be removed as soon as Chrome is updated to set the new function pointer.
+#if !defined(GR_GL_IGNORE_ES3_MSAA)
+    #define GR_GL_IGNORE_ES3_MSAA 0
+#endif
+
 /**
  * There is a strange bug that occurs on Macs with NVIDIA GPUs. We don't
  * fully understand it. When (element) array buffers are continually
  * respecified using glBufferData performance can fall off of a cliff. The
  * driver winds up performing many DMA mapping / unmappings and chews up ~50% of
  * the core. However, it has been observed that occaisonally respecifiying the
  * buffer using glBufferData and then writing data using glBufferSubData
  * prevents the bad behavior.
  *
  * There is a lot of uncertainty around this issue. In Chrome backgrounding
@@ skipping 10 matching lines @@
  * trick every 128 array buffer uploads.
  *
  * Hopefully we will understand this better and have a cleaner fix or get a
  * OS/driver level fix.
  */
 #define GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND   \
     (GR_MAC_BUILD &&                                    \
      !GR_GL_USE_BUFFER_DATA_NULL_HINT)
 
 #endif