[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