[cairo] [RFC] Add device_extents api
behdad at behdad.org
Tue Feb 3 09:25:48 PST 2009
The current implementation is broken indeed, and we plan to fix it. But why
new API? What you propose can "eassily" be done by installing an identity
matrix before the extents call. How is that not enough?
Jeff Muizelaar wrote:
> The current cairo_(stroke|fill|path)_extents api does not do what users want or
> expect. Here's some of the evidence of this:
> Currently, the stroke/fill/path extents functions compute the device space axis
> aligned bounding box, transform the bounding box back to user space and compute
> the user space axis aligned bounding box of that. In contrast, glyph_extents()
> computes the extents directly in userspace and should give expected results.
> An example of this is at http://people.mozilla.com/~jmuizelaar/extents.png. In
> this example, the yellow line is the path we compute the extents for. The green
> box is the what you'd probably expect as user space extents. The red box is
> what you'd expect for device space extents and the blue box is the extents that
> we return. I'm not really sure what use the blue box, perhaps someone can come up
> with a use case? Interestingly enough, the quartz
> CGContextGetPathBoundingBox() function returns the same 'weird' extents that we
>>From what I've seen, it looks like Firefox, libswfdec and moonlight all want the
> device extents and each try different tricks to achieve this.
> The attached patch adds cairo_(stroke|fill|path)_device_extents() which
> act the same as the current api but do not transform the extents back
> into userspace. The patch is large because it refactors the existing
> implementation to share a common device_extents implementation.
> Comments welcome,
> cairo mailing list
> cairo at cairographics.org
More information about the cairo