[cairo] Two small patches

Behdad Esfahbod behdad at behdad.org
Wed Jul 12 18:53:50 PDT 2006


On Sat, 2005-08-13 at 13:27 -0400, Keith Packard wrote:
> On Sat, 2005-08-13 at 01:08 -0700, Carl Worth wrote:
> > On Tue, 2 Aug 2005 21:38:03 -0400 (EDT), Behdad Esfahbod wrote:
> > 
> > >   - Does not err if there are excess elements in the path.
> > > Means, if there are more points than needed for an operation.
> > > This way applications may store private data in a path structure.
> > > Would be good to know if people see any obvious problem with
> > > allowing that.
> > > 
> > >   - Adds a CAIRO_PATH_NOOP operation, that cairo simply ignores.
> > > That's to expand the functionality from last item, to allow for
> > > application-specific operations.
> > 
> > What thoughts do people have on this addition?
> 
> Do we have a use case here? Or is it just for 'future proofing' the API?
> Without a compelling use case, I don't see enough intrinsic value to
> warrant this particular change.
> 
> I like value checking across the API as it catches errors earlier in the
> program. Please compell this change with some application which cannot
> easily be written without it.

Ok, now I have a use-case that this functionality is really desired:  I
want to parametrize a path, such that I can build a function p(t) ->
(x,y) that maps a "distance" on the path to the point on path.  Now to
make such queries faster, I want to compute the length of each path item
(line or curve) only once and cache it.  The easiest way I can think of
is to add an extra cairo_path_data_t at the end of LINE_TO and CURVE_TO
operation to keep cumulative and individual lengths.  Indeed I can
allocate a separate array and keep them there, but combining them in
cairo_path_t in a compatible way looks more beautiful to me.

> -keith

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"



More information about the cairo mailing list