[cairo] Mac Tiger Core Image

[Carl Worth]

On Thu, 10 Mar 2005 10:26:08 -0800, Bill Spitzak wrote:
> > There are at least two gaps that I am currently aware of, and for
> > which we've already started some discussion on the list:
> > 
> > 	General gradients
> > 
> > 	Filters
> 
> Add 3x3 transformation for patterns:

Yes, we are definitely considering something for this.

> Notice that 3x3 
> transformations for paths or anything other than patterns is not 
> necessary, it would be nice, but is not a requirement.

Non-affine transformations for paths is not being considered at
all. Cairo is a 2D graphics library, not a 3D graphics library. There
has to be a line somewhere, and that's where I put it.

> In my opinion we only need the ability to turn off antialiasing for 
> individual straight lineto's, perhaps with a new aliased-lineto call. 
[...]
>                                                             This is 
> absolutely necessary to draw solid complex objects, using "add" as 
> suggested in other postings will not work

Uhm, every solid complex object that you've ever seen cairo draw was
drawn by individually compositing the tessellated trapezoids with
"add" to an intermediate surface. So, not only will this work, it is
the only way that cairo ever has worked.

> We also need the ability to "adjust" the current transformation. Add 
> commands to round the transform so that the coordinate 0 in each 
> direction is put on the nearest pixel center, pixel edge, or both, and 
> set the scale so 1 unit is a multiple of .5, an integer, or an integer 
> plus .5. This will allow small objects to be drawn nicely, far better 
> than turning off antialiasing will allow.

The user has full control over the transformation already. And the
user can transform coordinates back and forth to see where the integer
boundaries are in device space. So the user has all the information
necessary in order to ask cairo to draw shapes that will align on
device-pixel boundaries. I've written example code showing how this
can be done (see cairo-demo/png/snapping.c).

The current semantics are well-defined and predictable. I'm not
interested in adding any magic adjustments that could change that.

I did experiment with adding unconditional snapping to a libsvg-cairo
and while it helps many object, it fails quite badly for feature sizes
smaller than one pixel. Compare:

http://cairographics.org/~cworth/images/cairo_logo_small.png
http://cairographics.org/~cworth/images/cairo_logo_small_snapped.png

That kind of trap is what makes me not want to put this kind of thing
into cairo. It's much better left at the level where SVG has it,
(ie. where the user can specify shape-rendering==crispEdges
vs. shape-rendering==geometricPrecision on an object by object
basis). As long as cairo support precise geometric rendering, it's
fairly easy for code above to push edges around to get crisp edges
when desired. But if cairo moves things around, it's awfully hard for
the code above to control things anymore.

-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/20050317/6c26df68/attachment.pgp