[cairo] Mac Tiger Core Image

[mental at rydia.net]

Quoting Bill Spitzak <spitzak at d2.com>:

> I believe this is the *only* way to fix the "antialiasing
> artifacts" you mentioned earlier while still allowing antialiasing
> around the outer boundary of the drawn object. Some triangles are
> going to be on the edge yet connect to interior triangles, they
> need this combined behavior.

What I specifically don't want is antialiasing around the outer
boundary of a drawn object, because it may cause undesirable
fringing during compositing, at least where "antialiasing" means
simulating partial coverage of pixels using the alpha channel.

The fringing occurs because the fringe pixels "pick up" some of
their background color after compositing; it is not due to any gaps
between (visually) adjacent polygons.

A little fringing is acceptable for interactive use, but not for
high-quality output (e.g. for RIP to film or production web
graphics).

Conversely, with or without antialiasing, Cairo should handle
boundaries between interior triangles just fine already as there is
not an intervening compositing step.

> Any device where the resolution is higher than the spread of the
> individual pixels (ie any printer at 1000 dpi or higher) is not
> going to need antialiasing, so it should be turned off.

That's certainly a good idea, although the resolution threshold for
turning off antialiasing is somewhat subjective.

> All the artifacts you listed reduce to being able to alias the
> straight edges of filled polygons, and only ones that adjoin
> adjacent polygons, so that drawing the adjoining polygons does not
> produce any partially or over-filled pixels.

The difficulty is that for my use cases the polygons may have to be
composited separately; there is no way around that.

I need to have the ability to avoid any anti-aliasing until after
all compositing is finished.

In lower-resolution situations where anti-aliasing is still
desirable, this means rendering and compositing at a multiple of
the target resolution with no antialiasing, then filtering the
result to produce an antialiased image at the desired resolution.

> I also do not want to see any api where textures are not sampled
> with a filter. Some graphics apis "turn off antialiasing" also
> point-samples the textures.

I agree that filtering and antialiasing should remain separate
considerations.  Turning off filtering is very seldom a desirable
tradeoff.

> If we think emulation of something stupid Microsoft did is
> important this will blow up by requiring emulation of this
> and many other quirks.

Let's refrain from emotional appeals, please.

> I do not like this, as it makes too many assumptions about
> implementations. If one of these actually turns off antialiasing,
> then people will complain if future implementations do not turn
> off antialiasing. So the abstraction just will not happen, people
> will just say "to turn off antialiasing do this".

Admittedly this does cut both ways -- it's possible that for a
particular surface type turning off antialiasing may actually prove
slower (it could e.g. involve a slower software fallback), so it
wouldn't do to tempt people into explicitly turning off
antialiasing as some kind of "go faster" switch either.

> If you disagree, please describe a graphic containing anything
> other than adjoining polygons where you believe turning off
> antialiasing will actually improve the output.

I think it would be more helpful if I provided a concrete example.

Take the following PostScript fragment:

 setgray 1
 0 0 moveto
 1.0 0 lineto
 1.0 1.0 lineto
 0 1.0 lineto
 fill

 setgray 0
 0 0 moveto
 0.5 0 lineto
 0.25 0.5 0.75 0.5 0.5 1.0 curveto
 0 0.5 lineto
 fill

 1.0 1.0 moveto
 0.5 1.0 lineto
 0.75 0.5 0.25 0.5 0.5 0 curveto
 1.0 0 lineto
 fill

(hopefully I got this right; I've not tested... the two shapes
should exactly mesh and cover a 1x1 square area)

To relate this to the more complex real-world situation, we will
assume that the three shapes is rendered and composited
individually.  In practice the latter two shapes would also
typically be filled with different patterns.  The choice of two
black shapes just makes the effect most obvious.

In renderers where the alpha channel is being used to simulate
partial coverage, then there will be a faint grey curve through the
middle of the black square -- this is assuming the renderer leaves
no gaps.

As far as I know, there are several ways around this:

 1. turn off antialiasing when rasterizing shapes, and perform
antialiasing yourself (if required) by filtering the image after all
compositing is complete [ I believe this is the approach taken by
e.g. Macromedia Flash ]

 2. dilate all shapes slightly before rendering so they overlap
sufficiently to eliminate fringing [ this is the approach taken by
the AntiGrain Geometry library ]

 3. maintain separate coverage and alpha masks throughout the
rendering/compositing pipeline [ IIRC the PDF rendering model does
this ]

#1 seemed the least onerous to implement in Cairo.

-mental