Menu
▾
▴
|
From: Pascal C. <pi...@gm...> - 2009-02-05 17:26:22
|
Hi everyone, I experienced some problems today, with overflows on floating point calculations, with rounding errors, or overflows in GDI rendering. The W3 specification says: 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. Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) for intermediate calculations on certain numerical operations. Within the SVG DOM, a <number> is represented as a float or an SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> . so even if they speak about float in end, it's all left to user choice before. My suggestion is to: - use double in SVG DOM (it also has the effect of speeding up computations, since it's the native format) - use float in SVG renderer and let the renderer do the conversion by itself (and check the overflows there). Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... |
|
From: Cort S. <cor...@gm...> - 2009-02-06 19:36:00
|
I don't see a problem with it off hand, without really putting a whole lot of thought into it. I do agree with the W3 comment though about getting the highest precision you can. I don't think I have come across this one in the past though, and I push a lot of SVG through the code. :) Cort On Thu, Feb 5, 2009 at 10:26 AM, Pascal Craponne <pi...@gm...> wrote: > Hi everyone, > I experienced some problems today, with overflows on floating point > calculations, with rounding errors, or overflows in GDI rendering. > The W3 specification says: > 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. > Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are > required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) > for intermediate calculations on certain numerical operations. > Within the SVG DOM, a <number> is represented as a float or an > SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> > . > so even if they speak about float in end, it's all left to user choice > before. > > My suggestion is to: > - use double in SVG DOM (it also has the effect of speeding up > computations, since it's the native format) > - use float in SVG renderer and let the renderer do the conversion by > itself (and check the overflows there). > > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
|
From: Pascal C. <pi...@gm...> - 2009-02-06 19:55:24
|
I had a sample with a very small float number (something like 1e-14) and it caused an error in the GDI. I fixed the problem by changing a string-to-number-to-string method, and that made me think that we should clearly differentiate what happens within SVG# from the renderer. On Fri, Feb 6, 2009 at 20:35, Cort Schaefer <cor...@gm...> wrote: > I don't see a problem with it off hand, without really putting a whole lot > of thought into it. I do agree with the W3 comment though about getting the > highest precision you can. I don't think I have come across this one in the > past though, and I push a lot of SVG through the code. :) > Cort > > On Thu, Feb 5, 2009 at 10:26 AM, Pascal Craponne <pi...@gm...> wrote: > >> Hi everyone, >> I experienced some problems today, with overflows on floating point >> calculations, with rounding errors, or overflows in GDI rendering. >> The W3 specification says: >> 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. >> Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are >> required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) >> for intermediate calculations on certain numerical operations. >> Within the SVG DOM, a <number> is represented as a float or an >> SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> >> . >> so even if they speak about float in end, it's all left to user choice >> before. >> >> My suggestion is to: >> - use double in SVG DOM (it also has the effect of speeding up >> computations, since it's the native format) >> - use float in SVG renderer and let the renderer do the conversion by >> itself (and check the overflows there). >> >> Pascal. >> >> jabber/gtalk: pa...@ja... >> msn: pa...@cr... >> >> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code >> to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Svgdomcsharp-developers mailing list >> Svg...@li... >> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> >> > |
