[cairo] Disabling antialiased shape drawing

[Owen Taylor]

On Wed, 2005-08-03 at 23:57 -0500, Billy Biggs wrote: 
>   Attached is a revival of David Reveman's patch [1] to disable
> antialiasing, with a slightly different API.  Rather than explicitly
> expose the details of how the shape is rendered, this new patch simply
> provides a "shape resolution" hint with two settings: default and low.
> 
>   Advantages of this approach:
> 
>    1. The API does not hold back new backends that may want to default
>       to higher quality shape rasterizing (rather than specify A8).
>    2. The API can be safely ignored by backends that do not require this
>       setting, such as the PS or PDF outputs.
> 
>   Disadvantages:
> 
>    1. LCD-optimized shape rendering will require a new API.
>    2. The hint is vague and therefore might be misinterpreted either
>       by backend implementors or API users.

So, what the patch has is:

typedef enum _cairo_shape_resolution {
    CAIRO_SHAPE_RESOLUTION_DEFAULT,
    CAIRO_SHAPE_RESOLUTION_LOW
} cairo_shape_resolution_t;

This to me implies that the question is one of "fidelity" - that the 
reason to use "LOW" is "better speed" or "don't care about quality",
but the most convincing arguments for being able to turn off
antialiasing were actually one of *higher* quality; to avoid mixing
per-channel alpha with shape alpha.

(This is most useful when oversampling with rendering then filtering
down later)

To me, this implies that we want something more like:

typedef enum _cairo_smoothing {
    CAIRO_SMOOTHING_NONE,
    CAIRO_SMOOTHING_NORMAL
} cairo_smoothing_t;

That doesn't make a "value" judgment. We could even reuse the existing:

typedef enum _cairo_antialias {
    CAIRO_ANTIALIAS_DEFAULT,
    CAIRO_ANTIALIAS_NONE,
    CAIRO_ANTIALIAS_GRAY,
    CAIRO_ANTIALIAS_SUBPIXEL
} cairo_antialias_t;

Used for fonts. Pro for reuse:

 - Having two similar but different enums is a recipe for people to
   pass the wrong one
 - Save types

Con for reuse:

 - Not clear how meaningful SUBPIXEL is for this. Subpixel geometry has
   some definite challenges.
 - We could theoretically want extension in a different direction -
   control the number of grayscale levels, for example. (I don't think
   that is that interesting though assuming that we can get decent
   performance with 255)

The other major comment about the patch is that I wouldn't convert
the gstate value to a format and pass it to the backend, but rather
I'd pass the gstate value to the backend and let it figure out
how to implement it. All backends don't necessarily work by rendering
geometry to a mask and compositing the mask. 

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050804/07b2c77c/attachment.pgp