Implement SkPicture::bytesUsed() for SkRecord backend

src/core/SkRecord.h

Index: src/core/SkRecord.h
diff --git a/src/core/SkRecord.h b/src/core/SkRecord.h
index 6019e0340683c9f2077b04c3868ace677c0e2687..521fd38014fc889a7a71469f596e9ee38004961c 100644
--- a/src/core/SkRecord.h
+++ b/src/core/SkRecord.h
@@ -30,7 +30,7 @@ class SkRecord : SkNoncopyable {
         kFirstReserveCount = 64 / sizeof(void*),
     };
 public:
-    SkRecord() : fCount(0), fReserved(0) {}
+    SkRecord() : fCount(0), fReserved(0), fBytesAllocated(0) {}
 
     ~SkRecord() {
         Destroyer destroyer;
@@ -68,6 +68,7 @@ public:
     template <typename T>
     T* alloc(size_t count = 1) {
         // Bump up to the next pointer width if needed, so all allocations start pointer-aligned.
+        fBytesAllocated += sizeof(T) * count;
         return (T*)fAlloc.alloc(sizeof(T) * count, SK_MALLOC_THROW);
     }
 
@@ -113,6 +114,10 @@ public:
         return fRecords[i].set(this->allocCommand<T>());
     }
 
+    size_t bytesUsed() const { return fBytesAllocated +
+                                      fReserved * (sizeof(Record) + sizeof(Type8)) +
+                                      sizeof(SkRecord); }
+
 private:
     // Implementation notes!
     //
@@ -231,6 +236,9 @@ private:
     // fCount and fReserved measure both fRecords and fTypes, which always grow in lock step.
     unsigned fCount;
     unsigned fReserved;
+
+    // counts bytes we've requested in fAlloc; *not* bytes in fRecords or fTypes
+    unsigned fBytesAllocated;

[mtklein, 2014/11/17 23:15:33]

Now that I'm thinking about it, it seems counterproductive to add a member here
just to track how large it is.  More than that, this fBytesAllocated will count
how many bytes we asked for, not how many we've allocated to serve that request.
 Ideally those scale well with each other, but the whole point of this is to
assert that, right?

How often do you guys figure you'll be calling ApproximateBytesUsed, and do you
care if it doesn't work on all platforms?  What about Debug vs. Release, etc?

SkVarAlloc could implement a byte-precise bytesAllocated() without any extra
memory usage at the cost of non-constant run time.  Mapping malloc_size /
malloc_usable_size / _msize down the chain of fPrev pointers should work, though
to date I haven't really liked to depend on non-standard methods like those
outside of debugging code.

[chrishtr, 2014/11/17 23:22:13]

It will only be when we want to collect debug info. But it needs to work in
production as well as debug environments, so we can integrate with
about:tracing.
non-constant runtime is probably ok so long as it isn't too slow. How slow are
we talking about?
Regarding debugging code: it'll only run when the page is under explicit debug
inspection (via the user turning on about:tracing, or us running
rasterize_and_record. So potentially unsafe or slow behavior is more acceptable.

 };
 
 #endif//SkRecord_DEFINED