Hi Om,
It may be that there might be better strategies depending on the size and
complexity of the SVG. For a single Rect there isn't very much "linear"
code.
For 5 or 6 objects, you might have:
var markup = "<svg>
<rect Š>
<rect Š>
<polygon Š>
<rect Š>
<circle Š>
<rect Š>
</svg>"
And I think there are child tags in SVG right?
The "linear" code theory says that, at least in AS, if you have to JIT
compile the linear code for that SVG which is your "Pure JS" example with
many more lines of code, at some point it is faster to use a loop like
this:
Var svgdata:Array = ["Rect", , , "Rect", , , "Polygon", , , , , "Rect", ,
, "Circle", , , "Rect", , , ]'
while (index < svgData.length)
{
switch (svgdata[index++])
case "Rect":
R = createElement("Rect")
R.setAttribute("x", svgdata[index++])
Š
break;
case "Polygon":
Š
}
That's because this "interpreter" gets "hot" since every SVG will use it
where as linear for a full UI might only get run once.
The other method I was thinking of was to use innerHTML. I just saw a
post on Mozilla forums that using innerHTML is "unreliable" so maybe that
won't work, but otherwise, that example would just look something like:
view = createElement("embed");
View.innerHTML = markup.
This theory says it is faster to concat strings and shove them into
innerHTML than to run any code at all. Strings also compress better than
code in AS, but the same trade-off doesn't apply to JS.
But I'm not surprised that DOMParser lost the race. BTW, are these
techniques going to work in IE8 or are we assuming HTML5 browsers only?
Thanks,
-Alex
On 2/28/14 11:58 PM, "OmPrakash Muppirala" <[email protected]> wrote:
>Alex:
>>
>The question is: what is the most efficient representation of FXG/SVG on
>> the JS side? Should it be SVG markup, or data structures that you can
>>use
>> to call the createElementNS/setAttributes in a loop? Or just linear JS
>> code making those calls? We stopped using linear AS code for MXML
>>codegen
>> because it is faster/smaller to generate a data structure and run a loop
>> where the JIT-compilation is re-used.
>>
>
>I did some performance benchmarks on the two ways to draw SVG using JS.
>The tests and the results are available here:
>http://jsperf.com/various-ways-of-drawing-svg-in-js
>
>The Pure JS method looks like this:
>
>var Rect = function(x, y, h, w, fill) {
>
> var NS = "http://www.w3.org/2000/svg";;
> var SVGObj = document.createElementNS(NS, "rect");
>
> SVGObj.width.baseVal.value = w;
> SVGObj.height.baseVal.value = h;
>
> SVGObj.setAttribute("x", x);
> SVGObj.setAttribute("y", y);
>
> SVGObj.style.fill = fill;
> return SVGObj;
>}
>
>The closest to a "SVG.innerSVG" would be using the DOMParser() to parse a
>SVG element xml and generate a DOM object out of it. The method looks
>like
>this:
>
>var domparser = new DOMParser();
>var RectXML = function(x, y, w, h, fill) {
>
> var rectElement = domparser.parseFromString(
> '<rect xmlns="http://www.w3.org/2000/svg"; x="' + x + '" y="' + y +
>'" width="' + w + '" height="' + h + '" style="fill:' + fill + '"/>',
>
> 'image/svg+xml');
> return rectElement.documentElement;
>}
>
>Running these two tests side by side, the pure JS method is much much
>faster than the DOMParser() method. The Pure JS method using the
>document.createElementNS() is clearly the favorite here.
>
>Alex, did you have any other technique in mind for us to performance test?
>I wasnt quite sure how to do the "data structures" way. Do you want to
>share a working snippet?
>
>Thanks,
>Om
