[cairo] Shouldn't Cairo use/offer degrees rather than radians?

[David Kastrup]

Gregor Mückl <GregorMueckl at gmx.de> writes:

> On 07/03/17 17:14, David Kastrup wrote:
>> [example code for drawing a half-circle omitted]
>
> Could you please explain why you chose that y value of
> 0.501954078674316 specifically? At first sight, it seems to be
> specifically designed to hit a pathological case.

Of course, because of the particular preceding discussion with Lawrence
D'Oliveiro.  I quote:

    >> Sigh.  If you cannot specify an angle for pi for which
    >> sin(angle)==0, you will have rasterizations of half circle arcs
    >> that won't line up perfectly because you then cannot make the
    >> half circles butt up perfectly, and "too small to be noticeable"
    >> becomes a statistic rather than a static feature under
    >> rasterization.
    >
    > There is no such situation.

This is a counterexample to the "there is no such situation claim" of
Lawrence.

> How big of an epsilon can you add to/subtract from this value before
> the output changes?

Quite small, of course: this value was bisected until failure.  I knew
that failure was going to happen (just like Lawrence knew that it
couldn't), so I took a half circle and chased the edge case down.  The
window is small since its size correlates to the inability of "double"
to properly represent pi.  It will be different for different floating
point implementations/representations.

The point is that radians are unable to represent important angles for
graphics operations in normal floating point formats and that there are
consequences.  They are more obvious for transform matrices but they are
even there for arcs.

> I haven't played around with the program.

It's an edge case.  Not more, but also not less.

-- 
David Kastrup