Solo gp

include/gpu/GrGeometryProcessor.h

+/*
+ * Copyright 2013 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef GrGeometryProcessor_DEFINED
+#define GrGeometryProcessor_DEFINED
+
+#include "GrProcessor.h"
+class GrBackendGeometryProcessorFactory;

[bsalomon, 2014/09/22 14:56:38]

Can this file live in src/gpu?

[joshua.litt, 2014/09/22 18:14:44]

I will move it in a future CL, along with the factories and such.  I want to
move GrProcessorStage out of include

+
+/**
+ * If an effect needs specialized vertex shader code, then it must inherit from this class.

[bsalomon, 2014/09/22 14:56:38]

How about something like:

A GrGeomteryProcessor is used to perform computation in the vertex shader and
add support for custom vertex attributes. A GrGemeotryProcessor is typically
tied to the code that does a specific type of high-level primitive rendering
(e.g. anti-aliased circle rendering). The GrGeometryProcessor used for a draw is
specified using GrDrawState. There can only be one geometry processor active for
a draw. The custom vertex attributes required by the geometry processor must be
added to the vertex attribute array specified on the GrDrawState.
GrGeometryProcessor subclasses should be immutable after construction.

+ * Otherwise it won't be able to add vertex attribs, and it might be given a vertexless shader
+ * program in emitCode.
+ */
+class GrGeometryProcessor : public GrProcessor {
+public:
+    GrGeometryProcessor() {}
+
+    virtual const GrBackendGeometryProcessorFactory& getFactory() const = 0;
+
+    static const int kMaxVertexAttribs = 2;
+    typedef SkSTArray<kMaxVertexAttribs, GrShaderVar, true> VertexAttribArray;

[bsalomon, 2014/09/22 14:56:38]

Is it really a max of two? Why use a dynamic array then?

Also we typically don't use SkSTArray as a param or return type. Rather we might
store an SkSTArray as a member of a class but it gets returned as SkTArray (the
base class). The caller of this getVertexAttribs shouldn't care that this is a
STArray and not a TArray.

[joshua.litt, 2014/09/22 18:14:44]

This is just because of GLProgramsTest.  Eventually this will not be the case. 
I will put a comment to that effect here with a TODO

On 2014/09/22 14:56:38, bsalomon wrote:

+
+    const VertexAttribArray& getVertexAttribs() const { return fVertexAttribs; }
+
+protected:
+    /**
+     * Subclasses call this from their constructor to register vertex attributes (at most
+     * kMaxVertexAttribs). This must only be called from the constructor because GrProcessors are
+     * immutable.
+     */
+    const GrShaderVar& addVertexAttrib(const GrShaderVar& var) {
+        SkASSERT(fVertexAttribs.count() < kMaxVertexAttribs);
+        return fVertexAttribs.push_back(var);
+    }
+
+private:
+    VertexAttribArray                            fVertexAttribs;
+
+    typedef GrProcessor INHERITED;
+};
+
+/**
+ * This creates an effect outside of the effect memory pool. The effect's destructor will be called
+ * at global destruction time. NAME will be the name of the created GrProcessor.
+ */
+#define GR_CREATE_STATIC_GEOMETRY_PROCESSOR(NAME, GP_CLASS, ARGS)                                 \
+static SkAlignedSStorage<sizeof(GP_CLASS)> g_##NAME##_Storage;                                    \
+static GrGeometryProcessor* NAME SkNEW_PLACEMENT_ARGS(g_##NAME##_Storage.get(), GP_CLASS, ARGS);  \
+static SkAutoTDestroy<GrGeometryProcessor> NAME##_ad(NAME);
+
+#endif