On Tue, Oct 21, 2008 at 1:05 PM, Neil Roberts <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-10-20 at 20:26 +0200, Arnaud VALLAT wrote:
>
>> on my working copy of clutter / cogl, I've added two new functions
>> which allow filling and stroking of paths with a texture. Basically it
>> computes texture coordinates according to path points. I've done this
>> because cogl does already everything on path such as bezier
>> computation and so on. The major problem is that each time
>> cogl_path_fill_with_texture is called it re-computes texture
>> coordinates, moreover if you have lots of path on your scene, you
>> compute each of them n times...
>
> That sounds very cool.
>
> How do you compute the texture coordinates? Does it still fill the path
> with the stencil buffer inverting trick?
I walk the cogl_path_nodes array and compute texture coordinates
according to the texture size and the bounding box of the path. It
results in an array of values between 0.0f et 1.0f. I don't use
stencil buffer because I didn't figure out how to use it ... So I give
texture coordinates to OpenGL using glTexCoordPointer, then I give
path coordinates using glVertexPointer and then call glDrawArrays.
Maybe it's not the perfect solution...
>
> I was thinking of doing something like this before but never got around
> to it. My idea was to calculate the stencil buffer for the path as
> normal and then just draw the texture instead of a rectangle. Is that
> similar to what you have done?
>
> Are you able to share your patch?
Yep sure, as soon as I reach home (I'm using clutter on a personal
project and can't do such a thing at work).
>
>> So, I'm also working on something else which exports path as a
>> CoglHandle. This avoid computation of path for each new form you would
>> make. It also allows the filling and stroking of path using a texture
>> as
>> above functions. With this design, everything is kept inside the
>> handle and avoids repeated computation.
>
> It might be worth waiting until the Mesh API [1] stuff is ready before
> starting this. We could potentially have some kind of cogl_path_to_mesh
> function to get the path as a mesh instead of having to create a whole
> new CoglHandle type for the path.
>
Yep, I've seen the Mesh API on the bugzilla, just got an answer today
on it :-). It seems it fits exactly my needs!
> The current approach for rendering paths using the stencil buffer isn't
> ideal in my opinion because we need to do a full stencil buffer clear
> for every fill. It would be much better if we could tessellate the shape
> into triangles and send the geometry to OpenGL. That would also play
> much nicer with the Mesh API.
>
> Thanks,
> - Neil
>
>
Thanks for your answer Neil.
Rno
--
"Given enough eyeballs, all bugs are shallow"
Eric Steven Raymond
--
To unsubscribe send a mail to [EMAIL PROTECTED]
