Simplifying SkLayerDrawLooper

[Matthew Dempsky]

An unrelated CL got me randomly looking at SkLayerDrawLooper; in particular the hand-rolled linked list implementation that seems unnecessarily complex.  Here's what I'm thinking, but wanted to vet the idea here because it touches Skia's public API:

  1. Add a SkLayerDrawLooper::Builder::reserve(size_t) function to allow callers to indicate how many layers they plan to add (similar to std::vector<T>::reserve).

  2. Change callers of addLayer to use addLayerOnTop instead.  (Turns out there's only one; see below.)

  3. Change Chromium and Blink to use the new reserve function.

  4. Remove SkLayerDrawLooper::Builder::addLayer.

  5. Change SkLayerDrawLooper and its Builder to use a std::vector<Rec> instead of a linked list of Recs.  addLayerOnTop uses push_back.  Builder::detachLooper can swap the vectors so it'll remain zero copy.

I looked through Android and Chromium and found:

  - Android doesn't use SkLayerDrawLooper at all.  (Just one use of SkBlurDrawLooper, which https://code.google.com/p/skia/issues/detail?id=2141#c7 suggests should be replaced by SkLayerDrawLooper.)

  - Blink only uses SkLayerDrawLooper::Builder's addLayerOnTop function; never its addLayer function.

  - Chromium has only one function that uses addLayer, and it looks like it could be easily converted to use addLayerOnTop instead: https://code.google.com/p/chromium/codesearch#chromium/src/ui/gfx/skia_util.cc&l=122

  - Further, both Blink and Chromium know how many layers they plan on adding to the SkLayerDrawLooper.  (Or at least they do within a couple of call frames; near enough that it wouldn't be hard to plumb that information through to SkLayerDrawLooper::Builder.)

Thoughts?

[Matthew Dempsky]

Proof-of-concept CL for step #2 is at crrev.com/1363253002, and for steps #1, #4, and #5 is at crrev.com/1362253002.