Make it possible to draw multiple paths at once to a draw target

Make it possible to draw multiple paths at once to a draw target

Add interface to draw multiple paths in a single "command" to a draw
target. Implement this interface in GrGpuGL with NVPR "instanced"
calls.

The instanced calls accept list of paths and list of transformations as
their parameters. The transformations are at this moment expected to be
2d affine transformations, as the functions are called only for text
rendering.

This will be used when drawing fonts. Later it can be maybe be used in
GrInOrderDrawBuffer to aggregate many draw calls into one instanced draw
call, similar to drawing rects.

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

[Kimmo Kinnunen, 2014-03-24 09:46:20]

Split the nvpr text patch into two

[Kimmo Kinnunen, 2014-03-24 13:09:40]

This is of course quite wide api vs. the difference of functionality it
provides. If need be, I can merge the two calls if the "api width" is a problem.

[bsalomon, 2014-03-24 13:53:24]

I'm ok with separate calls for single vs. multiple. Some minor comments, mostly
looking good.

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.h
File src/gpu/GrDrawTarget.h (right):

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
src/gpu/GrDrawTarget.h:350: * @param transforms array of 2d affine
transformations, one for each path.
Is it required that the transforms are affine? If so, I'd feel better about a
SkScalar[] param with 6 values per matrix (unless this really complicates life
for the callers).

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
src/gpu/GrDrawTarget.h:895: const GrDeviceCoordTexture*) = 0;
Can you name the GrDeviceCoordTexture? It's not completely obvious without some
context why there is a texture param here.

[Kimmo Kinnunen, 2014-03-24 13:58:50]

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.cpp
File src/gpu/GrDrawTarget.cpp (right):

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
src/gpu/GrDrawTarget.cpp:565: transforms[i].mapRect(&mappedPathBounds,
paths[i]->getBounds());
In practical terms, it would complicate and slow things here.

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.h
File src/gpu/GrDrawTarget.h (right):

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
src/gpu/GrDrawTarget.h:350: * @param transforms array of 2d affine
transformations, one for each path.
On 2014/03/24 13:53:24, bsalomon wrote:
> Is it required that the transforms are affine? If so, I'd feel better about a
> SkScalar[] param with 6 values per matrix (unless this really complicates life
> for the callers).

See the reply in the .cpp ->


Also:
API-wise, the commit msg insinuates multiple uses (drawpath "compacting") for
the api. if this becomes reality, the full expressivity is needed. Of course,
this needs a modification to the docstring, so we could also modify the API too,
at that point..

Which ever is the best from your FOV is fine for me.

[bsalomon, 2014-03-24 15:40:24]

On 2014/03/24 13:58:50, kkinnunen wrote:
>
https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.cpp
> File src/gpu/GrDrawTarget.cpp (right):
> 
>
https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
> src/gpu/GrDrawTarget.cpp:565: transforms[i].mapRect(&mappedPathBounds,
> paths[i]->getBounds());
> In practical terms, it would complicate and slow things here.
> 
> https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.h
> File src/gpu/GrDrawTarget.h (right):
> 
>
https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
> src/gpu/GrDrawTarget.h:350: * @param transforms array of 2d affine
> transformations, one for each path.
> On 2014/03/24 13:53:24, bsalomon wrote:
> > Is it required that the transforms are affine? If so, I'd feel better about
a
> > SkScalar[] param with 6 values per matrix (unless this really complicates
life
> > for the callers).
> 
> See the reply in the .cpp ->
> 
> 
> Also:
> API-wise, the commit msg insinuates multiple uses (drawpath "compacting") for
> the api. if this becomes reality, the full expressivity is needed. Of course,
> this needs a modification to the docstring, so we could also modify the API
too,
> at that point..
> 
> Which ever is the best from your FOV is fine for me.

Seems ok to leave as is. lgtm.

[Kimmo Kinnunen, 2014-03-25 11:18:24]

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget.h
File src/gpu/GrDrawTarget.h (right):

https://chromiumcodereview.appspot.com/209413006/diff/1/src/gpu/GrDrawTarget....
src/gpu/GrDrawTarget.h:895: const GrDeviceCoordTexture*) = 0;
On 2014/03/24 13:53:24, bsalomon wrote:
> Can you name the GrDeviceCoordTexture? It's not completely obvious without
some
> context why there is a texture param here.

Done.

[Kimmo Kinnunen, 2014-03-25 11:18:29]

The CQ bit was checked by kkinnunen@nvidia.com

[commit-bot: I haz the power, 2014-03-25 11:18:35]

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

[commit-bot: I haz the power, 2014-03-25 11:59:43]

Change committed as 13930