[docs][patch] [cla] Get Dojo GFX running on top of SVGWeb

[Chris Mitchell]

There are some quirks with doc root creation and events when using SVGWeb (​http://code.google.com/p/svgweb/) under Dojo GFX. Once this is running, we need to understand the performance of gfx+svgweb vs. VML and Silverlight renderers. If it performs well, we should consider embedding the SVGWeb library in dojo (as a flash binary). This would allow dojo users to have svg api's in IE, as well as h.264 video and audio tag support, along with GFX.

[Chris Mitchell]

We have SVGWeb working under gfx, and are doing performance tests. Initial patch coming soon.

[Chris Mitchell]

The biggest problem so far is: Flash needs time to startup before it can be used, so svgweb uses a callback to notify the readiness of its mock SVG object. This makes a trouble to dojo user as the Surface object returned by createSurface() is not immediately effective, only after Flash gets loaded, then the user can start to work with the surface object. See sample code below:

var node = dojo.byId("surface"); var surface = dojox.gfx.createSurface(node, 600, 600);

FIXME need a callback! must setTimeout to wait for flash to load, or the surface won't be usable setTimeout(function() {

start to work with surface basicShapes(surface); basicTransform(surface); basicGroup(surface); basicMove(surface);

}, 250);

Also, the event problem can be seen once you get past the above issue... in Moveable. The problem was dojo.connect() binds event listener by setting objonclick?; while svgweb only simulates obj.addEventListener(). My fix is to override the connect() methods on class Surface & Shape in svg.js with private impl, rather than delegate to dojo.connect().

[Chris Mitchell]

The workaround for the root node creation is to create a root svg element with SVGWeb programmatically, by calling svgweb._processSVGScript(/* a script element containing svg source */);

[Adam Peller]

Can the load timing problem be addressed at the DOM level with some sort of standard event on the SVG node? Are these things we've discussed with Brad? Dojo might not be the only code with these issues.

[Brad Neuberg]

Note that SVG Web isn't designed to be used without the JavaScript? side; you need both the JS and the SWF file. There are lots of tricky timing fixes that are in the JS. It's not possible for you to have Dojo GFX plug into those?

[Eugene Lazutkin]

I believe it has already been solved. I pinged chrism about that, but I didn't update the ticket.

Silverlight has two problems/features:

1. Its surfaces are created asynchronously.
2. It has no DOM, so all events are special callbacks.

My understanding SVGWeb has the same restrictions. So I advised chrism to take a look at silverlight.js and borrow necessary code --- the API is already there.

[Chris Mitchell]

Attaching the first patch to dojo gfx to enable it work with SVGWeb. Patch contributed by Yang Li (IBM Shanghai Lab) under CCLA.

============================================================ Install the patch

---

Just copy all the files to your dojo folder, overwrite on prompt of conflict. The resulted file structure should be similar to:

<web_root>

• dojo
• dojox
  • gfx
    • svg.js (overwrite)
    • tests
      • svgweb-test* (add)
• svgweb <== The latest distro of svgweb
  • src
    • svg.htc (add)
    • svg.js (add)
    • svg.swf (add)

============================================================ Enable or disable the SVGWeb with dojo gfx

---

The patched function is only enabled when SVGWeb JS is included and the gfx renderer is 'svg'. If either SVGWeb is not available or the renderer is not 'svg', the patch is disabled and should have no impact to dojo's gfx system in any way.

To enable SVGWeb with dojo gfx:

1. Include SVGWeb JS at the FIRST of all your javascripts

<meta name="svg.render.forceflash" content="true"/> <script src="<path>/svgweb/src/svg.js" data-path="<path>/svgweb/src"></script>

2. Force 'svg' renderer with the 'forceGfxRenderer' config

<script src="<path>/dojo/dojo.js" djConfig="forceGfxRenderer:'svg'" type="text/javascript"></script>

============================================================ Test dojo gfx + SVGWeb

---

Open the modified gfx test cases from your local web server like:

​http://localhost/<web_root>/dojox/gfx/tests/svgweb-test.roundrect.html ​http://localhost/<web_root>/dojox/gfx/tests/svgweb-test.....

============================================================ GFX Functional Test Status

---

Summary / General findings

• The performance of SVGWeb is generally slow
• The behavior is very consistent on IE & FF
• Image is not working
• Text is not working
• Line style is not working
• Transformation works but the output is not always correct

Thumbs up test.roundrect.html

Thumbs up test_arc.html

Thumbs up test_bezier.html

Thumbs up test_decompose.html

Thumbs up test_destroy.html

Thumbs up test_fill.html

XXX test_fx.html: partly works, but font is not shown

Thumbs up test_fx_shapes.html

Thumbs up test_gfx.html

Thumbs up test_gradient.html: works, but performance is very slow

XXX test_group1.html: partly works, but rect highlight change has problem

Thumbs up test_group2.html: works, with source changed from 'dijit.byId()' to 'dojo.byId()'

XXX test_image1.html: not work

XXX test_image2.html: not work

XXX test_image3.html: not work

XXX test_image4.html: not work

XXX test_image5.html: not work

Thumbs up test_linearGradient.html

XXX test_linestyle.html: not work

XXX test_pattern.html: not work (similar to image)

Thumbs up test_poly.html

Thumbs up test_resize.html

Thumbs up test_setPath.html

XXX test_tbbox.html: output drawing is incorrect

XXX test_text.html: not work

XXX test_textpath.html: not work

XXX test_transform.html: output drawing is incorrect

Thumbs up test_utils.html

Thumbs up test_vectortext_draw.html

XXX test_vectortext_load.html: output drawing is incorrect GFX performance on SVGWeb Test Results

General concerns: =================

Though have not run the DOH performance tests yet, the general feeling is that SVGWeb is slower than VML and Silverlight on IE7 in cases where there's heavy dynamic scripting over the Flash interface, but it does run consistently across browsers.

Not sure why the Gradient tests are so slow - approx 5secs to run them-- much slower than VML and SL.

Currently, test cases have to be modified to add <script> for svg.js. A solution that does not require direct inclusion of <script> should probably be looked into. Maybe a djconfig setting of svgweb should script inject svgweb into the dom for you? This probably depends on whether svgweb swf,js,and htc gets redistributed.

=========== Next steps:

Yang is working on:

• Remaining Text and Image api's to get GFX functionally complete on svgweb.
• Investigating why Gradient tests are taking so long.
• Running perf tests for comparison with VML, Silverlight

[Brad Neuberg]

I wonder if you can speed things up by using suspendRedraw and DOM Fragments. Details at ​http://codinginparadise.org/projects/svgweb/docs/QuickStart.html#tips . BTW, do you have the Umber Hulk release? We are also working on some refactoring that is not yet in the tree to drastically reduce the number of Flash Sprites on the page at once which should help performance.

[Chris Mitchell]

Latest SVGWeb Progress: ================================== Have completed analysis for each failing test case against known SVGWeb issues list, and fixed some additional test cases as a result of known workarounds.

We're testing on the latest svgweb *trunk* (update daily). suspendRedraw() *does* helps performance--a bit, the response time of test_gradient is reduced from 11997ms to 8631ms on IE7 and from 4885ms to 3121ms on FF 3.5, good improvement but still a little slow from a user point of view. We will investigate other areas where suspendRedraw() may be able to be leveraged (this should help performance in the general SVG case as well. We will begin investigation of use of DOM Fragments today.

We will note Dojo GFX blocking status in the blocking SVGWeb ticket system for the blocking issues found below.

Latest GFX Functional Test Status: ==================================

Summary / General findings

---

• The performance of SVGWeb is generally slower than VML and Silverlight on IE7 (needs further verification)
• The behavior is very consistent on IE & FF
• Transformation of Image is not working
• Transformation of Text is not working
• Line style is not working
• Transformation in general works but the output is not always correct

GFX Test Results

---

PASS test.roundrect.html PASS test_arc.html PASS test_bezier.html PASS test_decompose.html PASS test_destroy.html PASS test_fill.html

FAIL test_fx.html: mostly works, except for the transformation of text (svgweb bug 158)

PASS test_fx_shapes.html PASS test_gfx.html PASS test_gradient.html: works, but performance is slow due to the creation of a lot of shapes; using suspendRedraw() helps, but not much; current time is 8.5 seconds on IE7, 3 seconds on FF 3.5

FAIL test_group1.html: partly works, but rect highlight change has problem (svgweb bug 328)

PASS test_group2.html: works, with source changed from 'dijit.byId()' to 'dojo.byId()'

FAIL test_image1.html: picture shows, but move and transform has serious problem (svgweb bug 329)

FAIL test_image2.html: picture shows, but move and transform has serious problem (svgweb bug 293)

FAIL test_image3.html: picture shows, but move and transform has serious problem (svgweb bug 293)

FAIL test_image4.html: not work (svgweb bug 293) FAIL test_image5.html: not work (svgweb bug 293)

PASS test_linearGradient.html

FAIL test_linestyle.html: not work (svgweb bug 65)

FAIL test_pattern.html: not work (svgweb bug 330)

FAIL test_poly.html

PASS test_resize.html PASS test_setPath.html

FAIL test_tbbox.html: output drawing is incorrect (svgweb bug 328)

FAIL test_text.html: text shows, but the rotation still fails (svgweb bug 158)

FAIL test_textpath.html: not work (svgweb bug 169)

FAIL test_transform.html: output drawing is incorrect (svgweb bug 328)

PASS test_utils.html PASS test_vectortext_draw.html PASS test_vectortext_load.html: functionally, this works, but very very slow; Reduced the test case to print just 26 chars, in FF it takes 30+ seconds, in IE7 it's more than a minute...

[bill]

Marking as 1.5 to clear TBD tickets from 1.4 list.

[opichals]

Please, have a look at ​http://bugs.dojotoolkit.org/ticket/10269 for simple svg.js change that should also help in general.

[liyang]

The work of running GFX on top of SVGWeb is almostly done, this is a recap.

GFX funtion test pass rate 83% (25 out of 30). The stack is strong enough to support a online drawing tool (like the google doc one) -- basic shapes, path, group, transform, events, all ready to go.

GFX performance test result is good too. After tuning, SVGWeb is remarkably faster than VML in big drawings. Two performance proposals are under Eugene's review.

The remaining issues mostly depend on SVGWeb. The important ones are:

• Issue 296: Incorrect node.appendChild() impl (I got a patch under Brad's review)
• Issue 244: Incorrect clientX/Y in mouse events (I got a patch under Brad's review)
• Issue 417: Missing getBBox() impl for text nodes
• Issue 158: Doesn't support transformation of text
• Issue 65: Doesn't support line styles
• Issue 169: Doesn't support text path

Please find the attachment (svgweb patch 2010-03-02.zip) for the patch.

[Eugene Lazutkin]

(In [21708]) SVGWeb support from Yang Li, !strict, refs #9948.

[Eugene Lazutkin]

I couldn't commit svgweb (needed for testing) due to perceived "errors" in svgweb/src/svg.js by the pre-commit hook, which always runs. I asked Adam Peller to advise me.

[Eugene Lazutkin]

@Yang Li

On top of the problems mentioned in README-svgweb, I found other problems, which are present only in IE (I used IE6 ans IE8 to test):

1. dojox/gfx/tests/svgweb/sample.html (former gfx-svgweb-sample.html) doesn't work. It shows alert() "[object Error]".
2. All image tests fail. Probably because I switched from absolute URLs (like ​http://something/something.jpg) to local URLs (like something/something.js).

I did tests with the latest trunk version of SVGWeb and with the version you included for testing.

Please verify.

[Eugene Lazutkin]

(In [21716]) !strict, refs #9948 - adding the latest SVGWeb for testing purposes (modifying three regexes that break Rhino).

[Eugene Lazutkin]

Replying to elazutkin:

2. All image tests fail. Probably because I switched from absolute URLs (like ​http://something/something.jpg) to local URLs (like something/something.js).

Actually it is mentioned by Yang Li as ​http://code.google.com/p/svgweb/issues/detail?id=442 I just missed it.

[Eugene Lazutkin]

Related commits attributed to other ticket by mistake: [21717], [21718], [21719].

[Eugene Lazutkin]

BTW, bug 442 is marked as invalid, and the correct way to specify a link is provided (with an explicit namespace). Now that way we do it was the way required by existing browsers. I added a namespace and verified that it works in the latest versions of FF, Webkit, Opera, and Chrome. And it helped to show images on SVGWeb + IE.

[Eugene Lazutkin]

Replying to elazutkin:

1. dojox/gfx/tests/svgweb/sample.html (former gfx-svgweb-sample.html) doesn't work. It shows alert() "[object Error]".

Amazingly now it works, when I run it from our test server: ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/gfx/tests/svgweb/sample.html

It looks like both "extra" bugs are resolved now.

[liyang]

Just verified both "extra" bugs are gone on my local IE7. :-)

[Adam Peller]

(In [21771]) checked in fixes from liyang. !strict Fixes #10963, Refs #9948

[liyang]

There's a big bug in my previous patch. Please review "bugfix 2010-04-10.patch" and apply if OK.

[Eugene Lazutkin]

(In [21930]) Patch from Li Yang (thx!), !strict, refs #9948.

[Eugene Lazutkin]

(In [21931]) Added missing forceGfxRenderer, !strict, refs #9948.

[Eugene Lazutkin]

Reassigning to 1.6 to continue working on this feature.

[ben hockey]

Replying to elazutkin:

(In [21708]) SVGWeb support from Yang Li, !strict, refs #9948.

thanks for adding the ability to do batch changes - it's cut my rendering time by more than 40% (1166ms -> 683ms). it shows that using a fragment for a large number of updates can really improve performance.

[Brad Neuberg]

We've had alot of checkins for SVG Web since April that aren't in the Dracolisk release yet that might help Dojo GFX. Info on the latest checkins in the head of SVG Web:

​http://code.google.com/p/svgweb/wiki/ReleaseNotes#In_Development

[Eugene Lazutkin]

Just updated to today's trunk of SVGWEB (7/4/2010 r1205). Many things are fixed and work as expected. Still problems with:

• test_image3.html --- scaled images are clipped to the old bounding box.
• test_linestyle.html --- line styles are not supported.
• test_textpath.html --- text is not shown (this is an experimental feature of dojox.gfx, so it is OK, if it doesn't work with this renderer).

Overall the quality of SVG approximated is very much improved since April. Good work! The only real problem (for charting) is the missing line style. Still it is rarely used, yet some users asked for it.

[Eugene Lazutkin]

(In [22431]) gfx: updating SVGWEB to the latest trunk, !strict, refs #9948.

[Eugene Lazutkin]

(In [22432]) gfx: bugfix --- replacing document with dojo.doc, and document.createElementNS() with _createElementNS(), !strict, refs #9948, refs #7617.

[Eugene Lazutkin]

Apparently [21708] uses document.createElementNS(), which is missing on IE browsers making it impossible to use SVGWEB on IE browsers. I was expecting that SVGWEB will define it, but apparently I was wrong.

I fixed that (see the above commit), but now we have a problem with XML in SVGWEB (svg.js, line 557):

function xmlToStr(node, namespaces) {
  var nodeXML = (node._nodeXML || node);
  var xml;
  
  if (typeof XMLSerializer != 'undefined') { // non-IE browsers
    xml = (new XMLSerializer().serializeToString(nodeXML));
  } else {
    xml = nodeXML.xml;
  }
  
  // Firefox and Safari will incorrectly turn our internal parsed XML
  // for the Flash Handler into actual SVG nodes, causing issues. We added
  // a fake SVG namespace earlier to prevent this from happening; remove that
  // now
  xml = xml.replace(/urn\:__fake__internal__namespace/g, svgns);

At this point xml is undefined and the whole thing blows on calling replace(). Tracking things back:

• node._nodeXML is undefined => nodeXML = node.
• XMLSerializer is undefined => xml = node.xml.
• node.xml is undefined => xml is undefined.
• QED

Brad, should I file the bug with SVGWEB? Could you take a look (dojox/gfx/tests/svgweb/)? I bet it is something simple on our side. If it is impossible/hard to fix, I'll roll back SVGWEB and recent changes.

[Eugene Lazutkin]

(In [22465]) gfx: reverting the test version of svgweb to the latest official release: svgweb-2010-04-09-dracolisk, !strict, refs #9948.

[ben hockey]

i opened #11436 to request a small change to the behavior of batching - some of you might be interested.

[Chris Mitchell]

This feature is now working (with some limitations). Suggest we close this ticket, and create a new one for 1.8 to track updating svgweb and determining whether latest version helps fill remaining gaps.

[Eugene Lazutkin]

Replying to chrism:

Please open new ticket for the latest version of SVGWeb. Whatever we use now is very old.

[Chris Mitchell]

#12973 tracks further updates to svgweb support

[Adam Peller]

In [27041]:

Update README to reflect proper svgweb version from r22465, also remove redundant license info. Refs #9948, #12973