[cairo] Turning off antialiasing

[Bill Spitzak]

On Tuesday 19 October 2004 08:54 am, Carl Worth wrote:
> On Mon, 18 Oct 2004 11:39:48 -0700, Bill Spitzak wrote:
> > I do not think the proposed solution in the FAQ will do the job. First it
> > does not work if you do any scaling, making it impossible to make sharp
> > outlined rectangles at any transform other than the identity.
>
> The hard part about this is what effect does the user want? If I
> introduce a "scale by 1.5" should these magic lines now be 2 pixels wide?
> Still 1 pixel?

It would be 2 pixels in this case.

> What about a scale by 5 or 50?

It would be 5 or 50.

> This is a similar concern to Owen's misgivings about the default matrix
> and the scaling it introduces when DPI increases.
>
> > My proposal is that Cairo must support a special mode for stroking the
> > path. The requirements of this mode are:
>
> It is clear that cairo should help users draw graphics aligned to
> device-pixel boundaries. It's not just about horizontal and vertical
> elements though, and it's not just about stroking either. I was playing
> with small-radius, filled circles yesterday, (for the dot in the center
> of the radio button). The alignment of that circle with the device-pixel
> edges makes a huge difference in the perceived quality.

I believe you are right. Symmetric things, even if antialiased, need some 
ability to center on pixels or half-pixels.

> > 3. If the user translates one unit in a direction parallel to the pixel
> > grid and draws perpendicular lines they will touch or overlap such that
> > no partially transparent pixels are between them. Drawing a row of dots 1
> > unit apart must also produce a solid line. I think this means it must be
> > able to draw integer thicknesses greater than 1 and that dots must be
> > rectangles.
>
> It seems this requirement would cause some strange behavior with
> non-identity transforms, (particularly with diverse horizontal and
> vertical scale factors).

Yes, several parallel lines drawn would overlap and the resulting visible 
portions would come out different widths. If the scale is less than 1 than 
some of the lines would be lost. However from past experience I have 
determined that this is the only acceptable behavior. Gaps are very bad as 
the code often assummes the background is completely obscured. Only other 
alternative is to round each edge of the line to the nearest pixel, but this 
just means that *all* lines vary in width, not just the ones drawn touching 
and next to each other.

> > I believe this can be done by setting the line width to the larger of the
> > horizontal or vertical scale of the current transform and adjusting the
> > end points of horizontal and vertical lines and dots to lie 1/2 line
> > width from an integer, then doing the normal stroke algorithim.
>
> It's not a simple matter to make this adjustment satisfy requirement #1.
> Imagine the following shape to be filled then stroked, with integer
> x,y,width,height and real-valued epsilon within (0.5,1):
>
> 	cairo_rectangle (cr, x, y, width - epsilon, height - epsilon);
>
> If the adjustment involves adding 0.5 to all values and then rounding to
> the nearest half-integer, then the stroke will not completely obscure
> the edge of the fill.

No, I want it to adjust to the nearest half-pixel directly with no offset, 
except that integers always round right/down. So the right edge drawn at 
width-epsilon will fill the pixel at width-1, which is the antialiased column.

> 	  calling cairo_stroke_path, cairo_snap_path, cairo_fill

This would work. The same call could also modify the line width, so it will 
satisfy everything needed.

I think for the symmetric things like radio buttons, the ability to "snap" 
the transform might be useful. You should be able to round the translation to 
the nearest integer, integer+.5, or both, and round the scale so that a given 
dimension is an integer, integer+.5, or both. Since you can read the current 
matrix and write it back this call may be entirely local, though it may be a 
good idea to provide a sample implementation.