Creation of GrBatchAtlas and Distancefieldpathrenderer batch

src/gpu/GrBatchAtlas.h

+
+/*
+ * Copyright 2010 Google Inc.

[bsalomon, 2015/03/05 22:11:08]

copyrights on new files are all 2010

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef GrBatchAtlas_DEFINED
+#define GrBatchAtlas_DEFINED
+
+#include "GrDrawTarget.h"
+#include "GrTexture.h"
+#include "SkPoint.h"
+#include "SkTInternalLList.h"
+
+class GrBatchAtlas;
+class GrBatchTarget;
+class GrGpu;
+class GrRectanizer;
+
+// The backing GrTexture for a set of GrAtlases is broken into a spatial grid of GrPlots. When

[bsalomon, 2015/03/05 22:20:49]

for a GrAtlas, not a set of atlases, right?

[Jvsquare, 2015/03/06 15:45:36]

This comment block is from GrAtlas.h, so any changes here should be made there
as well. That said, there's a lot of duplicated code between GrBatchAtlas and
GrAtlas -- is it possible to subclass GrAtlas?

+// a GrAtlas needs space on the texture, it requests a GrPlot. Each GrAtlas can claim one

[bsalomon, 2015/03/05 22:20:49]

atlases claim plots or have plots?

+// or more GrPlots. The GrPlots keep track of subimage placement via their GrRectanizer. Once a
+// GrPlot is "full" (i.e. there is no room for the new subimage according to the GrRectanizer), the
+// GrAtlas can request a new GrPlot via GrAtlas::addToAtlas().

[bsalomon, 2015/03/05 22:20:49]

Maybe in here state somewhere that plots accumulate new data but we never
replace data in a plot, we spill to the next plot.

+//
+// If all GrPlots are allocated, the replacement strategy is up to the client. The drawToken is

[bsalomon, 2015/03/05 22:20:49]

Document that the unit of replacement is the plot? Or is that not a requirement?

[joshualitt, 2015/03/09 19:45:15]

I rewrote this entire comment in the cpp file

+// available to ensure that all draw calls are finished for that particular GrPlot.
+// GrAtlas::removeUnusedPlots() will free up any finished plots for a given GrAtlas.
+
+class GrBatchPlot : public SkRefCnt {

[bsalomon, 2015/03/05 22:20:49]

Do plots need to be exposed to client of GrBatchAtlas or can this be defined in
the GrBatchAtlas.cpp

I also wonder what about this is really "batch"? It seems pretty reusable
outside of the context of GrBatchTarget.

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+public:
+    typedef GrDrawTarget::BatchToken BatchToken;
+    SK_DECLARE_INST_COUNT(GrBatchPlot);
+    SK_DECLARE_INTERNAL_LLIST_INTERFACE(GrBatchPlot);
+
+    // This returns a plot ID unique to each plot in a given GrAtlas. They are

[bsalomon, 2015/03/05 22:20:49]

we usually use genID to mean an ID that changes when the object is modifed, and
uniqueID to mean an unchanging ID that refers to an object.

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+    // consecutive and start at 0.
+    int id() const { return fID; }
+    int generation() const { return fGeneration; }

[bsalomon, 2015/03/05 22:20:49]

comment about how this changes when content of the plot changes?

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+
+    GrTexture* texture() const { return fTexture; }
+
+    bool addSubImage(int width, int height, const void*, SkIPoint16*);
+
+    BatchToken lastUploadToken() const { return fLastUpload; }

[bsalomon, 2015/03/05 22:20:49]

These should be documented, esp lastRefToken 

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+    BatchToken lastRefToken() const { return fLastRef; }
+    void setLastUploadToken(BatchToken batchToken) { fLastUpload = batchToken; }
+    void setLastRefToken(BatchToken batchToken) { fLastRef = batchToken; }
+
+    void uploadToTexture();
+
+    void resetRects();
+
+    int x() const { return fX; }
+    int y() const { return fY; }
+
+private:
+    GrBatchPlot();
+    ~GrBatchPlot(); // does not try to delete the fNext field
+    void init(GrGpu*, GrBatchAtlas*, GrTexture*, int id, uint32_t generation, int offX, int offY,
+              int width, int height, size_t bpp);
+
+    BatchToken fLastUpload;
+    BatchToken fLastRef;
+
+    uint32_t fID;
+    uint32_t fGeneration;
+    unsigned char* fPlotData;
+    int fPlotWidth;

[bsalomon, 2015/03/06 16:34:59]

Do these really need plot in the name? The object type is plot.

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+    int fPlotHeight;
+    int fX;
+    int fY;
+    GrGpu* fGpu;

[bsalomon, 2015/03/06 16:34:59]

Does this really need the gpu object, should it be able to make all the API
calls on GPU? Does it need to be persistent.

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+    GrTexture* fTexture;
+    GrRectanizer* fRects;
+    GrBatchAtlas* fAtlas;
+    SkIPoint16 fOffset;        // the offset of the plot in the backing texture
+    size_t fBytesPerPixel;
+    SkIRect fDirtyRect;
+    SkDEBUGCODE(bool fDirty;)
+
+    friend class GrBatchAtlas;
+
+    typedef SkRefCnt INHERITED;
+};
+
+class GrPlotUpdater {

[bsalomon, 2015/03/05 22:11:08]

It really seems like this should be a generic uploader with a GrPlotUpdater
subclass.

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+public:
+    GrPlotUpdater() : fPlot(NULL) {}
+    GrPlotUpdater(GrBatchPlot* plot) : fPlot(SkRef(plot)) { SkASSERT(plot); }
+    GrPlotUpdater(const GrPlotUpdater& other)
+        : fPlot(SkRef(other.fPlot.get())) {
+        SkASSERT(other.fPlot);
+    }
+    GrDrawTarget::BatchToken lastUploadToken() const { return fPlot->lastUploadToken(); }
+    void update() { fPlot->uploadToTexture(); }
+
+private:
+    SkAutoTUnref<GrBatchPlot> fPlot;
+};
+
+typedef SkTInternalLList<GrBatchPlot> GrBatchPlotList;
+
+class GrBatchAtlas {
+public:
+    typedef GrDrawTarget::BatchToken BatchToken;
+    // An AtlasID is an opaque handle which callers can use to determine if the atlas contains
+    // a specific piece of data
+    typedef uint32_t AtlasID;
+
+    GrBatchAtlas(GrGpu*, GrTexture*, int numPlotsX, int numPlotsY);
+    ~GrBatchAtlas();
+
+    // Adds a width x height subimage to the atlas. Upon success it returns
+    // the containing GrPlot and absolute location in the backing texture.
+    // NULL is returned if the subimage cannot fit in the atlas.
+    // If provided, the image data will either be immediately uploaded or
+    // written to the CPU-side backing bitmap.
+    bool addToAtlas(AtlasID*, GrBatchTarget*, int width, int height, const void* image,
+                    SkIPoint16* loc);
+
+    GrTexture* getTexture() const { return fTexture; }
+
+    // A debug function to upload all plot data to the texture
+    void uploadPlotsToTexture();

[bsalomon, 2015/03/05 22:11:08]

SkDEBUGCODE()?

[joshualitt, 2015/03/09 19:45:15]

Acknowledged.

+
+    bool hasID(AtlasID id) {
+        int index = this->getIndexFromID(id);
+        SkASSERT(index < fNumPlotsX * fNumPlotsY);
+        return fPlotArray[index]->generation() == this->getGenerationFromID(id);

[bsalomon, 2015/03/05 22:20:49]

is this right? I would think that we'd be using id() not generation() here, but
probably just don't understand.

[joshualitt, 2015/03/09 19:45:15]

this is correct, I have renamed id to index to make things clearer(ie, if the
index and generation are the same, its the same plot)

+    }
+
+    void setLastRefToken(AtlasID id, BatchToken batchToken) {
+        SkASSERT(this->hasID(id));
+        int index = this->getIndexFromID(id);
+        fPlotArray[index]->setLastRefToken(batchToken);
+    }
+
+private:
+    int getIndexFromID(AtlasID id) {
+        return (id >> 16) & 0xffff;
+    }
+
+    int getGenerationFromID(AtlasID id) {
+        return id & 0xffff;
+    }
+
+    inline void updatePlot(GrBatchTarget*, AtlasID*, GrBatchPlot*);
+
+    void makeMRU(GrBatchPlot* plot);
+
+    GrGpu* fGpu;
+    GrTexture* fTexture;
+    int fNumPlotsX;
+    int fNumPlotsY;
+    int fPlotWidth;
+    int fPlotHeight;
+    size_t fBPP;
+
+    // allocated array of GrBatchPlots
+    SkAutoTUnref<GrBatchPlot>* fPlotArray;
+    // LRU list of GrPlots (MRU at head - LRU at tail)
+    GrBatchPlotList fPlotList;
+
+};
+
+#endif