Precision loss in VML renderer

[Eugene Lazutkin]

VML accepts only integral values as coordinates. As a consequence it can accumulate errors especially for long relative segments. We need to find a way to make it more precise by pre-calculating all values independently and using the closest point to the real value.

[guest]

elazutkin,

i think it might help to let you know how i worked around this one. I just drew the path at 1000 times the size I needed it, and then _transformed_ it...

M 2000,15 instead of M 2,0.015 transformation- xx: 0.001, yy: 0.001 (shrunk it back down)

But this is a heavy kludge. What is great is that VML is rendered to the thousandth pixel instead of single. Let me know if you want to see a working example.

bradley dott mccandless att gmail dott com [cla]

[Eugene Lazutkin]

Moving all open ticketd to the future.

[Eugene Lazutkin]

Apparently the loss is in the VML itself rather in our VML renderer. There are two ways around it:

1. Use Brandley's suggestion above.
2. Do not generate any relative commands always using the absolute segments calculating absolute values ourselves.

Both solutions break the introspection (planned, but not fully implemented at the moment). Probably we should forget about 1-to-1 introspection of paths in this case. I am inclined to try the second solution myself because it doesn't involve any trickery, and has a potential to reduce the codebase somewhat.

[Eugene Lazutkin]

(In [15160]) gfx: refs #4454, !strict; in order to improve the precision of the vml renderer all relative path commands are converted internally to use corresponding absolute commands; the path test is updated.

[Eugene Lazutkin]

Switching to absolute commands seems to improve the performance somewhat, reduced the codebase, and the code surface (== less code to debug).

This huge debug session highlighted bugs in VML's implementation of quadratic curves. Unfortunately the only way to improve that primitives is to approximate them with other primitives. This approach doesn't look practical though --- the abysmal performance of IE's JScript coupled with more math in JavaScript? code will negatively affect the performance of the renderer.