Adding the rendering canvas' CTM to the layer hoisting key (i.e., Add support for hoisting layers in pictures drawn with a matrix - https://codereview.chromium.org/748853002/) has increased the cache miss rate due to accumulated floating point error. This CL fixes part of the issue by using the chain of operation indices leading to each saveLayer as the key. The canvas' CTM must still form part of the key but should be less subject to accumulated error.
BUG=skia:2315
Review URL: https://codereview.chromium.org/753253002
- The expected case is now a single bulk-load insert() call instead of N;
- reserve() and flushDeferredInserts() can fold into insert() now;
- SkBBH subclasses may take ownership of the bounds
This appears to be a performance no-op on both my Mac and N5. I guess
even the simplest indirect branch predictor ("same as last time") can predict
the repeated virtual calls to SkBBH::insert() perfectly.
BUG=skia:
Review URL: https://codereview.chromium.org/670213002
Having hoisted layers from different pictures invalidates the assumptions of the old GrReplacements object. This is fixed by switching to a SkTDynamicHash-based back-end.
Sub-picture-layers also require that the replacement drawing occur for the sub-pictures too. The ReplaceDraw object is added to make this happen and limit the replacement lookup to saveLayer draw commands.
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
Review URL: https://codereview.chromium.org/607763008
This is intended to disconnect the lifetimes of the optimization data, cached layers and replacement objects.
Note that the optimization data already makes a copy of the paint in the SkPicture. Additionally the replacement object will probably go away at some point.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/579843002
