[cairo] Path as a resource

[Mike Emmel]

Good questions.

I'm trying to write up a example now.
I'm thinking about this now.

You hit all the main issues.

Let me see if I can code something up that makes sense.

Next of course I realized if  I can get paths to be good patterns then cairo_t's
can be patterns also.

The question is then how to handle the AffineTransform.
Patterns already have a transform so this may not be and issue.

Also Patterns are immutable.

So I think I can achieve my goal which is if I make paths patterns
then they can be considerd immutable and cairo can then convert them
to a fast form.

The basic form would be to stroke or fill  and create a surface
pattern then its a simple blit. But the idea is we can retain them in
tesslated form with everthing fixed except a final affine transform
before blitting.

So if I can git this to work in a sensible way I think doing cairo_t's
as patterns is simple
then you have a way to compile a arbitrary set of ops to either save
space or time or both.

And you have enough information to recover the original resources to
derive new similar patterns.

In many two 2D drawing cases most of the drawing is fixed or modified
only via the application of a affine transform.

In anycase if I can't come up with a reasonable way to represent paths
then this all falls apart.




On 11/10/06, Bill Spitzak <spitzak at d2.com> wrote:
> If there is a path object, it should be in device space. The
> transformation must be applied at the moment a point is added to the
> path. Extracting a path and then putting it back should have the
> appearance of removing the CTM when you get it and applying the
> (possibly different) CTM when you set it. If speed is a problem it may
> be a good idea to put the CTM into the path object so that it can apply
> the transforms at the same time when the path is set.
>
> Any operation on paths should replace the current path with the new one.
> Besides stroke and flatten, you might want to transform the path, and I
> could imagine erode/swell type operations being very popular too.
>
> Making the path be a surface is interesting. I would think a path would
> act just like a surface which is opaque white inside the path and
> transparent black outside it.
>
> To be consistent, you should be able to use a surface as the current
> path, which would ignore the color and treat the alpha channel of the
> surface as an indication of how much inside the path a pixel is. By far
> the biggest advantage of this is that it would allow the clip to be set
> to an image's alpha channel.
>
> This would complicate Cairo, however, as the compositing would have to
> allow a path or image to be used at any location in the math. Also if
> there is an operations such as stroke, should it do the edge detection
> necessary for any image used as the current path?
>
> Mike Emmel wrote:
> > I've been thinking about the concept of having paths as resource like
> > patterns or fonts.
>