[cairo] Extending Cairo API to support reusable paths

Matt Woodrow matt.woodrow at gmail.com
Wed Mar 31 13:51:50 PDT 2010


Thanks for the reply

I'd have no problem with cairo_shape_t, though it possibly implies a 
finalized shape and I am
trying to get it so you can continue to append to these paths after they 
have been applied.

The retained path object isn't tied to an context, but it will need to 
retain a pointer to the backend
it was created on. It can then use this to de-construct itself if passed 
to a different backend.

Hopefully I can store the native path objects in user coordinates and 
you can then apply new
transformations when the object is applied to a context (or when the 
object is drawn within a context).

Is there a use case for a separate constructor? It seems like it would 
be better to update the code to only
copied the retained path in the first place. That said, I think I need 
to implement a function of this nature
internally, so exporting it publicly wouldn't be an issue at all.

The current use I am trying to implement is SVG paths, yes. Not sure if 
it will be useful in other places
within our tree.

Thanks again

Matt Woodrow

On 31/03/10 8:28 PM, Benjamin Otte wrote:
> Hey, cool to see someone working on this again.
> I've wanted to have something like this since I started hacking on
> Swfdec a few years ago - it always seemed so wasteful to retesselate on
> every draw operation.
> It just turned out to be really hard to get this machinery right and a
> lot of people had different ideas, so it never moved anywhere.
>
> Also, my idea has always been to call this cairo_shape_t instead of your
> cairo_retained_path_t. Does that make sense?
>
>
> Some questions: What's the scope of this retained path object? Is it
> supposed to be bound to a cairo_t or even a specific matrix or can I use
> the same object in multiple different places?
>
> Which leads to the question if there should be constructors like
> cairo_shape_t *cairo_shape_create (cairo_path_t *path);
>
> Also, what use cases do you guys have in mind for this API? I suspect
> you want to use it as an object to represent SVG paths? Do you intend to
> use it for custom font handling, too? Anything else?
>
> I'm really excited to see this moving again.
>
> Benjamin
>
>
> On Wed, 2010-03-31 at 09:50 +1300, Matt Woodrow wrote:
>    
>> Hi All
>>
>> As part of my internship at Mozilla, I'm working on extending the Cairo
>> API to allow caching of reusable path objects.
>>
>> On the default backend, these will directly wrap the current
>> cairo_path_t objects, and their related functions.
>> However on Quartz we can include a copy of the CGPath object and on
>> direct2d a copy of the ID2D1Geometry to hopefully increase redraw
>> performance on these platform.
>>
>> The API changes I am proposing are:
>>
>> /* New cairo API */
>> typedef struct _cairo_retained_path cairo_retained_path_t;
>>
>> cairo_public cairo_retained_path_t *
>> cairo_copy_retained_path(cairo_t *cr);
>>
>> cairo_public void
>> cairo_append_retained_path(cairo_t *cr, cairo_retained_path_t *path);
>>
>> cairo_public void
>> cairo_retained_path_destroy(cairo_retained_path_t *path);
>>
>>
>> Does anyone have any thoughts, questions or suggestions on this?
>>
>> The Mozilla bug for this is at
>> https://bugzilla.mozilla.org/show_bug.cgi?id=555877
>>
>> Thanks
>>
>> Matt Woodrow
>> --
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>>      
>
>
>    


More information about the cairo mailing list