Re: Circular paths

Cameron McCormack:
>
> Although reading the text there now I see that it requires normalizing
> arcs into straight line segments!

But it does not say, how many straight line segments.
If you do this, obviously it depends on the curve size in 
device pixels as well to meet the required accuracy for
the display in SVG.
My estimate is, that if the arc length is L device pixels,
you need in the order of L straight line segments, maybe
only 0.5L to meet the rule to be accurate within one
device pixel. 

Alex Danilo:
> 
>       The entire point of having arcs in the path syntax is to have
> accurate curves for things like rivers in maps, etc, etc. We do not
> use Beziers in our implementation. Just sin() and cos() as should be
> used for an arc. A Bezier approximation will always result in error.

Because you try to present arbitrary paths (river paths or coast lines
are fractal structures) everything you paint is a dramatical simplification,
There is no perfection.
Elliptical arc segments are typically useful to represent elliptical arcs,
I think, they are not really useful to approximate arbitrary curves like
rivers or coast lines etc, because those are no elliptical arcs and
cubic curves are much easier to handle for approximation.

And if there are limitations due to a library or maybe due to performance
issues, it is a good questions how to approximate in such a way that
there is no difference within the required accuracy. As long as the
audience cannot see the difference, one can use the most effective
method. But of course, to be sure, that the audience will never see
the difference, this can require a lot of theoretical efforts.
Indeed, without such careful efforts my estimate is, that the result
will be annoying for some authors, because the accuracy
requirement is not met under some conditions.

But if someone has a nice method for "If you use cubic paths to
approximate elliptical arcs, do it for example this way to meet
the accuracy requirement" - why not to add it as infomative hint for
implementors in the appendix just to avoid bad approximations, if
an implementor really decides to approximate for whatever reason.
The decision, how to meet the accuracy requirement and to have
an effective implementation should be left to the implementor, therefore
only informative hints, just to avoid really bad implementations.
And if there is no such simple method, but someone is able to
write down the exact definition of the problem to solve,
this might help too (maybe a nice task for a mathematician).

Authors have to approximate most paths anyway, basically with
cubic curves to be presentable with SVG - everything is approximation
finally. And at least my 'experimental' numerical approaches to
approximate paths like elllipses, spirals, trigonometric functions,
exponential functions, solutions of differential equations etc are clearly
not the optimal solution concering effectiveness. Therefore my assumption
is, that others including implementors have similar problems - why not
to discuss how to do it better? Good and fast implementations matter
for authors as well - for example if the approximation is not effective, it
takes more time to render the path data and for an animated path this
means no smooth interpolation between two values, because it takes
too long to calculate one interpolation result.

Olaf

Received on Tuesday, 8 March 2011 10:40:48 UTC