W3C home > Mailing lists > Public > www-svg@w3.org > March 2000

Re: DOM Interface for SVGPathElement

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Tue, 07 Mar 2000 13:34:36 -0800
Message-Id: <200003072131.NAA12214@mail-345.corp.Adobe.COM>
To: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
Cc: "'www-svg@w3.org'" <www-svg@w3.org>
Curt,
I see your point. I'll bring this up to the working group.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

At 09:37 AM 3/7/00 -0700, Arnold, Curt wrote:
>I would like to suggest an additional method be added to the SVGPathElement
>that would optimizes the addition of common x,y path segments while
>still allowing the full flexibility of the existing model to be used.
>
>Currently to add an moveto segment to a path, you would need to
>do something like this (in a VB like pseudo code)
>
>Dim pathSeg as SVGPathSeg
>set pathSeg = pathElem.createSVGPathSeg
>pathSeg.pathSegType = SVG_PATHSEG_MOVETO_ABS
>pathSeg.x = 0
>pathSeg.y = 0
>pathElem.pathSegList.append pathSeg
>
>The code has approximately 7 calls which if late-bound VB would add a
>comparable number of calls to IDispatch::GetIDsOfNames and IDispatch::Invoke.
>
>Since this could be a very high frequency call, 
>there could be a substantial performance improvement as well as a
simplification
>of client code, if in addition to this existing methods, an additional
method named
>something like "appendSeg" was added to SVGPath element.  Something like:
>
>void appendSeg(unsigned short pathSegType,x,y)  raises (SVGException);
Received on Tuesday, 7 March 2000 16:31:54 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:18 GMT