Beginning to refactor nvpr code

src/gpu/gl/GrGpuGL.cpp

 /*
  * Copyright 2011 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 
 #include "GrGpuGL.h"
 #include "GrGLStencilBuffer.h"
@@ skipping 1853 matching lines @@
         GR_GL_CALL(gl, StencilOp(glFailOp, glPassOp, glPassOp));
     } else {
         GR_GL_CALL(gl, StencilFuncSeparate(glFace, glFunc, ref, mask));
         GR_GL_CALL(gl, StencilMaskSeparate(glFace, writeMask));
         GR_GL_CALL(gl, StencilOpSeparate(glFace, glFailOp, glPassOp, glPassOp));
     }
 }
 }
 
 void GrGpuGL::flushStencil(const GrStencilSettings& stencilSettings, DrawType type) {
+    // TODO figure out why we need to flush stencil settings on path draws at all

[Kimmo Kinnunen, 2014/11/03 20:39:12]

Can you expand on this, what is the unknown part or why do you think the stencil
settings are not needed?
When drawing the paths (e.g. covering the paths), the covered pixels are changed
based on the stencil values. The way they're changed is defined by the stencil
settings

[bsalomon, 2014/11/03 20:49:34]

Our thought was that stencilSettings is more expressive than NVPR allows. The
fill type seems sufficient at the GrDT level. However, the clipping code needs
to be able to munge the stenciling in order to respect the current clip which
does require more expressiveness than just the fill type. We were thinking the
clipping code would read the fill type and then produce something for
GrGpu/GrPathRendering that more closely matches the semantics of NVPR than the
StencilSettings struct.

     if (kStencilPath_DrawType != type && fHWStencilSettings != stencilSettings) {
         if (stencilSettings.isDisabled()) {
             if (kNo_TriState != fHWStencilTestEnabled) {
                 GL_CALL(Disable(GR_GL_STENCIL_TEST));
                 fHWStencilTestEnabled = kNo_TriState;
             }
         } else {
             if (kYes_TriState != fHWStencilTestEnabled) {
                 GL_CALL(Enable(GR_GL_STENCIL_TEST));
                 fHWStencilTestEnabled = kYes_TriState;
@@ skipping 26 matching lines @@
 #if 0
     // Replace RT_HAS_MSAA with this definition once this driver bug is no longer a relevant concern
     #define RT_HAS_MSAA rt->isMultisampled()
 #else
     #define RT_HAS_MSAA (rt->isMultisampled() || kDrawLines_DrawType == type)
 #endif
 
     const GrRenderTarget* rt = optState.getRenderTarget();
     if (kGL_GrGLStandard == this->glStandard()) {
         if (RT_HAS_MSAA) {
-            // FIXME: GL_NV_pr doesn't seem to like MSAA disabled. The paths
-            // convex hulls of each segment appear to get filled.
-            bool enableMSAA = kStencilPath_DrawType == type ||
-                              optState.isHWAntialiasState();
+            bool enableMSAA = optState.isHWAntialiasState();
             if (enableMSAA) {
                 if (kYes_TriState != fMSAAEnabled) {
                     GL_CALL(Enable(GR_GL_MULTISAMPLE));
                     fMSAAEnabled = kYes_TriState;
                 }
             } else {
                 if (kNo_TriState != fMSAAEnabled) {
                     GL_CALL(Disable(GR_GL_MULTISAMPLE));
                     fMSAAEnabled = kNo_TriState;
                 }
@@ skipping 640 matching lines @@
             this->setVertexArrayID(gpu, 0);
         }
         int attrCount = gpu->glCaps().maxVertexAttributes();
         if (fDefaultVertexArrayAttribState.count() != attrCount) {
             fDefaultVertexArrayAttribState.resize(attrCount);
         }
         attribState = &fDefaultVertexArrayAttribState;
     }
     return attribState;
 }