Re: ISSUE-2113 (animate-elem-35): animate-elem-35 [Test Suite - SVG Tiny 1.2]

> In regard to this issue:
>
>
> --Original Message--:
> >ISSUE-2113 (animate-elem-35): animate-elem-35 [Test Suite - SVG  
> Tiny 1.2]
> >
> >http://www.w3.org/Graphics/SVG/WG/track/issues/2113
> >
> >Raised by: Doug Schepers
> >On product: Test Suite - SVG Tiny 1.2
> >
> >Piers Wombwell
> ><http://lists.w3.org/Archives/Public/www-svg/2008Oct/0039.html>:
> >[[
> >Just had a quick glance at your test suite results, and noticed a
> >comment against test animate-elem-35.
> >
> >The problem here is down to fixed point maths. The inside of the 'A'
> >is made from a path using relative co-ordinates which don't map well
> >to fixed point maths. So when it draws the horizontal line to  
> complete
> >the path in the bottom-right, the end point doesn't quite match the
> >start point. The closepath then expects the current point to be equal
> >to the start point, but they aren't quite, and so it draws a sub-one-
> >pixel line -- and so the line joins aren't as expected. Rather than
> >one line join between the last and first lines (_ and \), there will
> >be two line joins, one between the _ and the short closepath, and one
> >between the short closepath and the first line \.
> >
> >I assume the problem is the same on the outer part of the 'A', but
> >haven't confirmed this.
> >
> >I'm not sure what precision you need for the test to pass, but
> >floating point tends to pass and fixed point (24.8) fails in my
> >experience.
> >]]
>
> SVG Tiny 1.2 Section 4 'Data Types' clearly states:
>
> "<number> values in conforming SVG Tiny 1.2 content must have no  
> more than 4 decimal digits in the fractional part of their decimal  
> expansion and must be in the range -32,767.9999 to +32,767.9999,  
> inclusive. It is recommended that higher precision floating point  
> storage and computation be performed on operations such as  
> coordinate system transformations to provide the best possible  
> precision and to prevent round-off errors."
>
> This is based on 1.1 Tiny and the discussion at  the time mandated  
> 16.16 as the precision for
> fixed point implementations. Ikivo passes and I recall it's fixed  
> point internally.
>
> 4 decimal digits after the decimal point requires 16 bits. A 24.8  
> format can at best represent
> 2 digits after the decimal point.
>
> Failures due to a 24.8 fixed point implementation unfortunately  
> can't be used as a failure
> due to the lack of support for the required accuracy mandated in  
> section 4.
Hi Alex,

I was explaining why implementations are failing the test rather than  
claiming the test is invalid.

I haven't tried it with 16.16 precision so I don't know if that's  
enough to pass. Given the precision of a number in base 10 number  
doesn't map directly to the number of bits in fixed point, there's a  
chance it doesn't.

Our implementation has chosen to ignore the 16.16 precision rule  
because it doesn't provide enough range on a TV. A HD screen can be  
1920 pixels wide, which only gives you a range of 17 screenfuls  
horizontally before it wraps. This isn't enough for things like  
scrolling EPGs and the like which need at least 24 hours of data. I  
appreciate on a mobile phone the screen is a fraction of the width so  
it is much less of a problem.

Piers.

Received on Saturday, 11 October 2008 10:57:37 UTC