Initialize writen paths and strokerecs lazily during GPU drawPath

Initialize written paths and strokerecs lazily during GPU drawPath

Initialize SkPaths and SkStrokeRecs lazily during GPU drawPath calls.
The constructors seem to appear in some profiler results on ARM (~1%).

Committed: http://code.google.com/p/skia/source/detail?r=13069

[Kimmo Kinnunen, 2013-12-18 10:22:56]

.. though the profiler setup I'm using is not perhaps the most reliable. 

This doesn't make any observable difference on the wall clock, so it's up to you
to decide if this is redundant.

[bsalomon, 2013-12-18 15:20:04]

I can't imagine it's ever worse and doesn't seem overly complex, so lgtm.

https://codereview.chromium.org/118143002/diff/20001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/118143002/diff/20001/src/gpu/GrContext.cpp#ne...
src/gpu/GrContext.cpp:1153: const SkPath* pathPtr = &path;
Could we not use SkTCopyOnFirstWrite for tmpPath/pathPtr as well? I suspect
pathPtr just predates the existence of SkTCopyOnFirstWrite, but maybe I'm wrong.

https://codereview.chromium.org/118143002/diff/20001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.chromium.org/118143002/diff/20001/src/gpu/SkGpuDevice.cpp#...
src/gpu/SkGpuDevice.cpp:867: const SkPaint& paint, const SkMatrix*
prePathMatrix,
Not recommending for this change, but maybe we could pass this function an
object similar to SkTCopyOnFirstWrite, where the code that sets up the object
gets to decide if the initial T is mutable or not.

[Kimmo Kinnunen, 2013-12-19 06:30:01]

https://codereview.chromium.org/118143002/diff/20001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/118143002/diff/20001/src/gpu/GrContext.cpp#ne...
src/gpu/GrContext.cpp:1153: const SkPath* pathPtr = &path;
On 2013/12/18 15:20:04, bsalomon wrote:
> Could we not use SkTCopyOnFirstWrite for tmpPath/pathPtr as well? I suspect
> pathPtr just predates the existence of SkTCopyOnFirstWrite, but maybe I'm
wrong.

Nope. tmp path is not a *copy* the incoming path, rather stroke of it.. IOW the
copy would be wasted..

The underlying thought in the question maybe highlights the missing support for
a common pattern in SkTLazy (SkTInitOnFirstWrite with less cumbersome name)..
Same would be usable in the other hunk of this patch.

https://codereview.chromium.org/118143002/diff/20001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.chromium.org/118143002/diff/20001/src/gpu/SkGpuDevice.cpp#...
src/gpu/SkGpuDevice.cpp:867: const SkPaint& paint, const SkMatrix*
prePathMatrix,
On 2013/12/18 15:20:04, bsalomon wrote:
> Not recommending for this change, but maybe we could pass this function an
> object similar to SkTCopyOnFirstWrite, where the code that sets up the object
> gets to decide if the initial T is mutable or not.

Yeah, in theory that'd be useful for couple of common parameters in couple of
functions -- mostly path, paint, stroke in 'draw*' here and Gr -side. I thought
about related thing for Gr*, passing COW strokes. That affects the API, so I let
it be.

The NV guy in me would probably encourage to go more along the lines of ensuring
data is immutable and GPU does everything. Like: instead of template trickery,
make sure paths are never stroked with CPU, transforms never applied in the
client code and paint properties never need any modification through the call
chain :-)

[commit-bot: I haz the power, 2014-01-14 18:18:12]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/kkinnunen@nvidia.com/118143002/40001

[commit-bot: I haz the power, 2014-01-14 18:42:36]

Change committed as 13069