Implement tesselated path renderer

This CL implements a tesselated path renderer, using GLU's libtess.  All of the fill modes except hairline are supported.  Note that the path renderer is not enabled by default; to enable it, replace "GrCreatePathRenderer_none.cpp" with "GrCreatePathRenderer_tesselated.cpp" in skia.gyp, and run gyp_skia, and build.

This change also contains a number of build fixes for Win32 (for building SampleApp on VS2008) and Mac (for my ancient Mac Pro which supports GL_EXT_framebuffer_object but not GL_ARB_framebuffer_object).  Also, priorityq-heap.c was removed from the SampleApp build, since it's #included by priorityq.c (weird, I know).

NB:  when this change is rolled into skia, some modifications to chromium's skia.gyp will be necessary.

[bsalomon, 2011-03-25 21:17:32]

Not knowing the GLU tessellator I can't really comment on how you're using it,
but I assume that part is all right :)

My only significant concern is that I don't think we want to require the GLU
tesselator in order to build Gr. Can we pull the GrTessellatedPathRenderer out
of GrPathRenderer.h/cpp? We can move all the helper funcs to some shared place
(e.g. GrPathUtils.h/cpp or some such). 

I'm thinking about path renderers as similar to font engines in skia proper. You
just build the ones you might want to use. In the long run we'll probably make
the "default" one optional as well (GrStenciledPathRenderer).

http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h
File gpu/include/GrPathRenderer.h (right):

http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h#new...
gpu/include/GrPathRenderer.h:178: GrPathFill fill) const { return true; }
Shouldn't this be false? Maybe this is leftover from before I fixed the calling
code in GrGpu? (Or maybe that is still broken?)

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp
File gpu/src/GrPathRenderer.cpp (right):

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
gpu/src/GrPathRenderer.cpp:632: static bool is_inverse_fill_type(GrPathFill
fill) {
We've got a IsFillInverted(GrPathFill) function.

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
gpu/src/GrPathRenderer.cpp:803: // yet another copy.
How is this handled in the existing C2D code?

[Stephen White, 2011-03-28 15:44:03]

On 2011/03/25 21:17:32, bsalomon wrote:
> Not knowing the GLU tessellator I can't really comment on how you're using it,
> but I assume that part is all right :)
> 
> My only significant concern is that I don't think we want to require the GLU
> tesselator in order to build Gr. Can we pull the GrTessellatedPathRenderer out
> of GrPathRenderer.h/cpp? We can move all the helper funcs to some shared place
> (e.g. GrPathUtils.h/cpp or some such). 

Sure, done.  I moved the helper funcs to the base class; let me know what you
think.

> I'm thinking about path renderers as similar to font engines in skia proper.
You
> just build the ones you might want to use. In the long run we'll probably make
> the "default" one optional as well (GrStenciledPathRenderer).
> 
> http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h
> File gpu/include/GrPathRenderer.h (right):
> 
>
http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h#new...
> gpu/include/GrPathRenderer.h:178: GrPathFill fill) const { return true; }
> Shouldn't this be false? Maybe this is leftover from before I fixed the
calling
> code in GrGpu? (Or maybe that is still broken?)
> 
> http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp
> File gpu/src/GrPathRenderer.cpp (right):
> 
>
http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
> gpu/src/GrPathRenderer.cpp:632: static bool is_inverse_fill_type(GrPathFill
> fill) {
> We've got a IsFillInverted(GrPathFill) function.
> 
>
http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
> gpu/src/GrPathRenderer.cpp:803: // yet another copy.
> How is this handled in the existing C2D code?

[Stephen White, 2011-03-28 15:44:16]

http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h
File gpu/include/GrPathRenderer.h (right):

http://codereview.appspot.com/4289072/diff/1/gpu/include/GrPathRenderer.h#new...
gpu/include/GrPathRenderer.h:178: GrPathFill fill) const { return true; }
On 2011/03/25 21:17:32, bsalomon wrote:
> Shouldn't this be false? Maybe this is leftover from before I fixed the
calling
> code in GrGpu? (Or maybe that is still broken?)

Whoops, yes; forgot to update this.  Fixed.

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp
File gpu/src/GrPathRenderer.cpp (right):

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
gpu/src/GrPathRenderer.cpp:632: static bool is_inverse_fill_type(GrPathFill
fill) {
On 2011/03/25 21:17:32, bsalomon wrote:
> We've got a IsFillInverted(GrPathFill) function.

Thanks; fixed.

http://codereview.appspot.com/4289072/diff/1/gpu/src/GrPathRenderer.cpp#newco...
gpu/src/GrPathRenderer.cpp:803: // yet another copy.
On 2011/03/25 21:17:32, bsalomon wrote:
> How is this handled in the existing C2D code?

In the existing code, the vertices and indices vectors are appended to by the
tessellator if necessary (as here), and those vectors are sent directly to the
command buffers.  Since AutoReleaseGeometry owns its own arrays, I can't really
do that here, since I'd need to allocate the AutoReleaseGeometry up front and
grow its vectors on self-intersections.

[Stephen White, 2011-03-28 15:45:03]

Responding to comments

[bsalomon, 2011-03-28 17:53:05]

On 2011/03/28 15:44:16, Stephen White wrote:
w is this handled in the existing C2D code?
> 
> In the existing code, the vertices and indices vectors are appended to by the
> tessellator if necessary (as here), and those vectors are sent directly to the
> command buffers.  Since AutoReleaseGeometry owns its own arrays, I can't
really
> do that here, since I'd need to allocate the AutoReleaseGeometry up front and
> grow its vectors on self-intersections.

When you say they are sent directly to the command buffers does that mean that
they are copied to VBs provided by the cmd buffer?

If instead of using ARG after the tessellator you say
GrDrawTarget::setVertexSourceToArray that should just turn into a glBufferData.

[bsalomon, 2011-03-28 17:55:33]

On 2011/03/28 15:44:03, Stephen White wrote:
> On 2011/03/25 21:17:32, bsalomon wrote:
> > My only significant concern is that I don't think we want to require the GLU
> > tesselator in order to build Gr. Can we pull the GrTessellatedPathRenderer
out
> > of GrPathRenderer.h/cpp? We can move all the helper funcs to some shared
place
> > (e.g. GrPathUtils.h/cpp or some such). 
> 
> Sure, done.  I moved the helper funcs to the base class; let me know what you
> think.

Hmm... it seems like these funcs are specific to two subclasses but not to the
parent class. It might be better to have non-class helper funcs or make a new
parent class to default and tessellated that provides the helper functions.

[Stephen White, 2011-03-28 19:29:09]

Move curve evaluation funcs to (new) SkPathUtils

[Stephen White, 2011-03-28 19:30:27]

Fix gyp file

[Stephen White, 2011-03-28 19:39:03]

On 2011/03/28 17:55:33, bsalomon wrote:
> On 2011/03/28 15:44:03, Stephen White wrote:
> > On 2011/03/25 21:17:32, bsalomon wrote:
> > > My only significant concern is that I don't think we want to require the
GLU
> > > tesselator in order to build Gr. Can we pull the GrTessellatedPathRenderer
> out
> > > of GrPathRenderer.h/cpp? We can move all the helper funcs to some shared
> place
> > > (e.g. GrPathUtils.h/cpp or some such). 
> > 
> > Sure, done.  I moved the helper funcs to the base class; let me know what
you
> > think.
> 
> Hmm... it seems like these funcs are specific to two subclasses but not to the
> parent class.

My thinking is that if those are the only two subclasses, and both of them use
that functionality, it's common.  :)

> It might be better to have non-class helper funcs or make a new
> parent class to default and tessellated that provides the helper functions.

Done.

[bsalomon, 2011-03-28 20:29:46]

> My thinking is that if those are the only two subclasses, and both of them use
> that functionality, it's common.  :)

Yeah, yeah I know :) I was just thinking that if we wrap Ken's L-B code in a
GrPathRenderer, for example, it might no longer be common.

Anyway, LGTM.

[bsalomon, 2011-03-28 20:29:48]

> My thinking is that if those are the only two subclasses, and both of them use
> that functionality, it's common.  :)

Yeah, yeah I know :) I was just thinking that if we wrap Ken's L-B code in a
GrPathRenderer, for example, it might no longer be common.

Anyway, LGTM.

[bsalomon, 2011-03-28 20:30:10]

http://codereview.appspot.com/4289072/diff/10011/gpu/src/GrGLInterface.cpp
File gpu/src/GrGLInterface.cpp (left):

http://codereview.appspot.com/4289072/diff/10011/gpu/src/GrGLInterface.cpp#ol...
gpu/src/GrGLInterface.cpp:150: #if GL_EXT_framebuffer_object && !GR_MAC_BUILD
I tested this on 10.6.6 and it compiles fine. I'm not sure why it was there.
Hopefully no one will yell at us. This code isn't long for the world anyway.

[Stephen White, 2011-03-28 20:48:25]

Landed as http://code.google.com/p/skia/source/detail?r=1012, closing.