Refactor SkRecord opts, converting playback optimizations where possible.

tests/RecordTest.cpp

 /*
  * Copyright 2014 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #include "Test.h"
 
 #include "SkRecord.h"
@@ skipping 28 matching lines @@
 DEF_TEST(Record, r) {
     SkRecord record;
 
     // Add a simple DrawRect command.
     SkRect rect = SkRect::MakeWH(10, 10);
     SkPaint paint;
     SkNEW_PLACEMENT_ARGS(record.append<SkRecords::DrawRect>(), SkRecords::DrawRect, (rect, paint));
 
     // Its area should be 100.
     AreaSummer summer;
-    record.visit(summer);
+    for (unsigned i = 0; i < record.count(); i++) {

[f(malita), 2014/04/22 12:16:10]

This loop appears quite common - can we set up a helper?

[mtklein, 2014/04/22 15:36:27]

Added apply() to AreaSummer, Stretch, and the others like it in the various
Record*Test.cpp files.

I'm skeptical about adding (back) a helper like this to SkRecord itself.  I
confused myself once when I accidentally used mutators that needed custom
iteration with the old let-SkRecord-drive mutate(F&) method.  Led to some funky
crashes.  As far as I can see, only tests and ~SkRecord() ever iterate in strict
order, and that's limited enough that I'm happy to rewrite this loop a couple of
times for them.

Sort of also a gut principle of mine, that if it's something the client code can
do just as efficiently, it's usually best to let the client do it.  If that
efficiency story changes, of course, this whole essay becomes moot.  :)

+        record.visit(i, summer);
+    }
     REPORTER_ASSERT(r, summer.area() == 100);
 
     // Scale 2x.
     Stretch stretch;
-    record.mutate(stretch);
+    for (unsigned i = 0; i < record.count(); i++) {
+        record.mutate(i, stretch);
+    }
 
     // Now its area should be 100 + 400.
-    record.visit(summer);
+    for (unsigned i = 0; i < record.count(); i++) {
+        record.visit(i, summer);
+    }
     REPORTER_ASSERT(r, summer.area() == 500);
 }