Fix minor undercounting in SkRecord::bytesUsed().
authormtklein <mtklein@chromium.org>
Mon, 13 Apr 2015 19:17:02 +0000 (12:17 -0700)
committerCommit bot <commit-bot@chromium.org>
Mon, 13 Apr 2015 19:17:02 +0000 (12:17 -0700)
When an SkRecord has more than kInlineRecords ops in it (today, 5 or more), the
current logic undercounts the bytes used by the SkRecord by sizeof(Record) *
kInlineRecords, i.e. 32 bytes.  This isn't a huge deal... by the time you've
recorded 5 ops, we're typically up around 1KB anyway, and it's only ever off by
that constant 32 bytes, so somewhere between 3% to 0% error as the picture grows.

But now that I've noticed, we might as well fix it.  Basically, this is a
reminder that the inline space used to store those first kInlineRecords ops
goes to waste once we pass that threshold.  In contrast, fInlineAlloc, the
space we preallocate for the SkVarAlloc, never goes to waste.  It always holds
the first few ops' data even when we grow past it.

BUG=skia:

Review URL: https://codereview.chromium.org/1081433002

src/core/SkRecord.cpp

index c2008a8..349fbf6 100644 (file)
@@ -22,7 +22,11 @@ void SkRecord::grow() {
 }
 
 size_t SkRecord::bytesUsed() const {
-    return fAlloc.approxBytesAllocated() +
-           (fReserved - kInlineRecords) * sizeof(Record) +
-           sizeof(SkRecord);
+    size_t bytes = fAlloc.approxBytesAllocated() + sizeof(SkRecord);
+    // If fReserved <= kInlineRecords, we've already accounted for fRecords with sizeof(SkRecord).
+    // When we go over that limit, they're allocated on the heap (and the inline space is wasted).
+    if (fReserved > kInlineRecords) {
+        bytes += fReserved * sizeof(Record);
+    }
+    return bytes;
 }