[cairo] API request: obtain the trapezoids that are outside of the surface

[Carl Worth]

On Mon, 16 Aug 2004 20:39:37 +0200, Jost Boekemeier wrote:
> Consider the following code:
> 
>   cairo_set_target_surface(cairo_surface_create(20, 20));
>   cairo_new_path();
>   cairo_move_to(0, 0);
>   cairo_line_to(1000, 10000);
>   cairo_stroke();
> 
> Now I would like to know if the above path fits onto the surface and, if
> not, I need a way to retrieve the trapezoids that cairo has discarded.

I'm not sure exactly what you want here.

One thing I should point out is that currently cairo doesn't discard any
geometry even when it exceeds the bounds of the current target surface,
(or the bounds of the current clip region).

It happily tessellates the trapezoids and then hands those trapezoids
off to the backends. And I think some of the backends are even dumb
enough to rasterize each traepzoid and hand the result off to the
compositor.

So as you can see, there are probably some significant savings to be had
by adding some geometry culling to cairo.

> What do you think about the following API function:
> 
> extern boolean 
> cairo_current_path_discarded(cairo_t			*cr,
> 		    cairo_move_to_func_t	*move_to,
> 		    cairo_line_to_func_t	*line_to,
> 		    cairo_curve_to_func_t	*curve_to,
> 		    cairo_close_path_func_t	*close_path,
> 		    void			*closure);

This API provides a result in terms of path primitives, (not trapezoids
like you suggest in the subject). But cairo doesn't currently have any
exported interface for discovering the resulting trapezoids, (whether
they fit on the surface or not).

If you do actually want a path result, not trapezoids, that would be a
bit trickier still. There is a well-defined operation that could be
described as the intersection of the current path with the current
clipping path, but we don't currently have code in cairo to compute
that. And Keith and I have hoped to avoid the need to have to put that
code into cairo. (Implementing robust set-theoretic operators for
polygons is similar to the current tessellation work, but a fair bit
tricker in spots. Not to mention if we wanted to generalize this to
include actual splines in the computation rather than polygonal
approximations).

-Carl