- From: Smailus, Thomas O <Thomas.O.Smailus@boeing.com>
- Date: Thu, 19 Feb 2015 21:20:11 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- CC: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Rik Cabanier <cabanier@gmail.com>, www-svg <www-svg@w3.org>
Interesting. Good to know. That single precision limitation would possibly limit the applicability of SVG for engineering diagram usage, where the need for rapid frame rendering is typically not of value, but range and precision are. Thomas -----Original Message----- From: Cameron McCormack [mailto:cam@mcc.id.au] Sent: Thursday, February 05, 2015 14:32 To: Smailus, Thomas O Cc: Amelia Bellamy-Royds; Rik Cabanier; www-svg Subject: Re: Numerical Limits in SVG coordinates? Smailus, Thomas O: > Which brings me back to my original question – should we put some > numerical precision guidance in the standard, that says something like > “conforming viewers implement floating point as at least 32 bit > precision in both mantissa and exponent, and integers with at least 32 > bit precision” or maybe IEEE 754 64 bit precision or ‘something’ > so that SVG creators have an expectation to target? We already have this section: https://svgwg.org/svg2-draft/types.html#Precision which is kind of hand wavey, but I would interprete to mean “attributes/properties must at least accept the full range of IEEE 754 single precision finite numbers, and calculations for rendering etc. must also be done with single precision”. This of course makes software based on Cairo compiled in fixed point mode non-conforming. Requiring IEEE 754 double precision would definitely make Firefox non- conforming, and I don’t think we could easily change. Our graphics library (that wraps Cairo, D2D, CoreGraphics etc.) uses single precision values, and I think that decision was made because single precision is used in GPU hardware, where more and more of the graphics processing is happening. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 19 February 2015 21:20:51 UTC