[cairo] Change of _cairo_meta_surface_get_extents

[Carl Worth]

On Fri, 05 May 2006 19:02:25 +0200, Emmanuel Pacaud wrote:
> -    rectangle->width = CAIRO_MAXSHORT;
> -    rectangle->height = CAIRO_MAXSHORT;
> +    rectangle->width = meta->width_pixels;
> +    rectangle->height = meta->height_pixels;
> 
>      return CAIRO_STATUS_SUCCESS;
>  }
> 
> If I've understood correctly the purpose of get_extents, it's not the
> right fix. But I'm not sure any backend implements get_extents the way
> it should.

The "should" here comes from the documentation describing the behavior
of _cairo_surface_get_extents which currently reads:

	/**
	 * _cairo_surface_get_extents:
	 * @surface: the #cairo_surface_t to fetch extents for
	 *
	 * This function returns a bounding box for the surface.  The
	 * surface bounds are defined as a region beyond which no
	 * rendering will possibly be recorded, in otherwords,
	 * it is the maximum extent of potentially usable
	 * coordinates.  For simple pixel-based surfaces,
	 * it can be a close bound on the retained pixel
	 * region.  For virtual surfaces (PDF et al), it
	 * cannot and must extend to the reaches of the
	 * target system coordinate space.
	 */

If some of the "virtual" surface types are violating this, then they
are buggy.

> Ok to push ?

Not as is, (so thanks for asking). The best analysis we have so far is
"other surfaces have this bug, so let's add it to meta-surface as
well". I don't find that compelling.

I don't think the "must extend" semantics were written
gratuitously---there is almost certainly at least one caller of
_cairo_surface_get_extents that depends on this behavior (or at the
very least, there was when this comment was written).

The patch above would be acceptable only with analysis that determined
that the above semantics are not necessary, and also a change to the
documentation above.

Otherwise, (and what might be easier), would be the the addition of a
new function with different semantics, (that match the needs of the
particular caller you are dealing with now). It would be nice to make
the name of the new function capture the semantics more
precisely. For example, the documentation above talks about
"potentially usable coordinates" but it sounds like the call that is
giving you trouble cares more about the extents of the "contents" that
have already been drawn.

So maybe the above function is get_usable_extents and the new one
would be get_contents_extents? get_drawing_extents? (Whatever, I won't
be too picky about the specific name here since it's not public API so
we still have the freedom to change it later if we can improve it).

The advantage of adding a new function is that the analysis can happen
incrementally and callers can be moved over one by one. The
disadvantage is that adding new surface backend functions is always a
bit of a pain, (eventually I'd like the backend interface to start
shrinking and not just keep growing).

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060505/e781136a/attachment.pgp