[cairo] [RFC] cairo_path_extents()

[Carl Worth]

On Mon, 21 Jan 2008 13:24:23 -0800, Carl Worth wrote:
> There is the alternate definition of cairo_path_extents, (which
> incidentally I had just added to the documentation), which is that
> cairo_path_extents is equivalent to cairo_stroke_extents as the line
> width approaches (but never reaches) zero. With that definition, then
> a degenerate move_to;line_to pair to the same point should be
> considered for cairo_path_extents but a bare move_to should not be.
>
> Shall we just go with that? Anyone have an argument why we shouldn't?
>
> With this definition, if someone has a use case where they really
> *want* individual points to be considered for cairo_path_extents, then
> they can do cairo_move_to;cairo_line_to in the same way that people do
> that for drawing non-zero-sized "dots" with cairo_stroke.

Here's my proposed patch. Also, please see cworth/path-extents for the
entire series I'm about to push to master.

This patch actually adds more state to the cairo_path_bounder which is
annoying, (for a moment I thought that _cairo_path_bounder_move_to
would become a no-op and _cairo_path_bounder_add_point could be folded
into _cairo_path_bounder_line_to, but that doesn't work).

I might follow this up by instead making the new state just be the
conventional current_point and has_current_point. That should be much
easier to read and will actually drop the state necessary from two
Booleans to one.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-cairo_path_extents-to-ignore-lone-cairo_move_to.patch
Type: application/octet-stream
Size: 0 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080121/10faf20a/attachment.obj