Refactor SkRecord opts, converting playback optimizations where possible.

Refactor SkRecord opts, converting playback optimizations where possible.

This adds back two optimizations from SkPicture: drawPosText strength reduction to drawPosTextH, and pointless save-foo-restore blocks are noop'd away.

The small-T optimization in SkRecord gets in the way of implementing replace(), so I removed it.

Just to keep the API focused, I removed the methods on SkRecord that iterate over i for you; it's just as efficient to do it yourself, and all of the interesting code does its own custom iteration.

BUG=skia:2378
Committed: http://code.google.com/p/skia/source/detail?r=14300

[mtklein, 2014-04-21 21:49:16]

I had originally developed a rather more aggressive refactoring that changed
SkRecord's guts significantly, but I realized today I couldn't separate the
effects of the new optimizations I was adding and that big refactor.

This CL is just the optimizations I've had floating around, and the API changes
needed to support them.  (Mostly, adding replace to SkRecord.)

[f(malita), 2014-04-22 12:16:09]

lgtm

https://codereview.chromium.org/245853002/diff/20001/tests/RecordTest.cpp
File tests/RecordTest.cpp (right):

https://codereview.chromium.org/245853002/diff/20001/tests/RecordTest.cpp#new...
tests/RecordTest.cpp:49: for (unsigned i = 0; i < record.count(); i++) {
This loop appears quite common - can we set up a helper?

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

lgtm

https://codereview.chromium.org/245853002/diff/20001/tests/RecordTest.cpp
File tests/RecordTest.cpp (right):

https://codereview.chromium.org/245853002/diff/20001/tests/RecordTest.cpp#new...
tests/RecordTest.cpp:49: for (unsigned i = 0; i < record.count(); i++) {
On 2014/04/22 12:16:10, Florin Malita wrote:
> This loop appears quite common - can we set up a helper?

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.  :)

[commit-bot: I haz the power, 2014-04-22 15:36:36]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/245853002/40001

[commit-bot: I haz the power, 2014-04-22 16:57:52]

Change committed as 14300