Add a GrLayerCache to GrContext

Add a GrLayerCache to GrContext

The GrLayerCache will cache the pre-rendered saveLayers.

This CL requires https://codereview.chromium.org/217423014/ (Minor changes to GrFontCache system) land first.

BUG=skia:2315

[bsalomon, 2014-04-01 15:26:35]

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.cpp
File src/gpu/GrLayerCache.cpp (right):

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.cpp#new...
src/gpu/GrLayerCache.cpp:75: const GrAtlasedLayer*
GrLayerCache::findLayer(SkPicture* picture, int id) {
Seems like this should be named something like findOrCreateLayer() since it
doesn't just find.

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h
File src/gpu/GrLayerCache.h (right):

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h#newco...
src/gpu/GrLayerCache.h:48: SkPicture*      fPicture;
A bare ptr?

[bsalomon, 2014-04-01 15:32:00]

How hard would it be to make the owner of the texture (GrAtlasMgr?) use
GrResourceCache. I hate to claim another 4MB of dedicated texture memory that
might not get used by some clients.

The owner's key should never change so it can compute it once. To avoid lots of
cache lookups (e.g. one per glyph) it might need the client to give it lock() /
unlock() blocks. For SkPicture playback we could lock it when picture playback
begins and unlock when finished (if there are atlas-cachable layers in the
picture).

[robertphillips, 2014-04-01 15:49:50]

Right - I want to do that (i.e., use a cached texture) for both the LayerCache
and the FontCache. I think that is a separate CL though.

[robertphillips, 2014-04-01 16:51:49]

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.cpp
File src/gpu/GrLayerCache.cpp (right):

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.cpp#new...
src/gpu/GrLayerCache.cpp:75: const GrAtlasedLayer*
GrLayerCache::findLayer(SkPicture* picture, int id) {
On 2014/04/01 15:26:35, bsalomon wrote:
> Seems like this should be named something like findOrCreateLayer() since it
> doesn't just find.

Done.

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h
File src/gpu/GrLayerCache.h (right):

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h#newco...
src/gpu/GrLayerCache.h:48: SkPicture*      fPicture;
I would greatly prefer a GenID on pictures.

[bsalomon, 2014-04-01 16:59:04]

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h
File src/gpu/GrLayerCache.h (right):

https://codereview.chromium.org/217343006/diff/1/src/gpu/GrLayerCache.h#newco...
src/gpu/GrLayerCache.h:48: SkPicture*      fPicture;
On 2014/04/01 16:51:49, robertphillips wrote:
> I would greatly prefer a GenID on pictures.

Is that something that could reasonably be done first? This seems really unsafe.
A new picture could easily have the same address as a deleted picture. I kind
feel like we let in bare ptrs for clipstacks thinking we'd fix in not too long
and it's been in there forever now.

[robertphillips, 2014-04-02 19:28:38]

PTAL - this now uses the SkPicture's generation ID

[bsalomon, 2014-04-02 20:52:19]

lgtm. This makes me even less happy that GrContext.h is public, but that's not
the fault of this CL in any way.

[robertphillips, 2014-04-03 00:27:53]

The CQ bit was checked by robertphillips@google.com

[commit-bot: I haz the power, 2014-04-03 00:27:56]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/robertphillips@google.com/217343006/4...

[robertphillips, 2014-04-03 00:33:54]

The CQ bit was unchecked by robertphillips@google.com

[robertphillips, 2014-04-03 00:34:52]

committed as r14038