Project

Profile

Help

Remarks on performance with SVG

Added by Manfred Staudinger over 8 years ago

I've uploaded a new version of my architectural drawing[1]. If we watch closely how the display develops, we can see three different stages[2]:

  • a. the main drawing shows up
  • b. a few tiny texts get visible
  • c. the heading and the table are ready

You'll notice how fast stage (a) is reached. If I don't count those under @display="none"@ this still involves processing 1026 @path@ elements[3].

To get from (a) to stage (b) it takes about 5 seconds even it means processing "only" 617 @text@ elements, because each character has to be transformed into @path data@. These are child elements to 2 container elements @g@ (with @id="g2_text"@ and @id="g3_text"@) and if I replace their attribute @stroke="black"@ by @stroke="none"@ this time goes down to about 3 seconds. Finally if I delete those 601 @text@ elements to which @visibility="hidden"@ applies (those show up only after a user action), (b) comes up together with (a).

The last stage belongs to Saxon-CE and takes about 4 seconds. Not too bad, but it was only possible after drastically reducing the size of the @data-source@. It does not point anymore to the main XHTML with 1.932.765 bytes but to a separate file of 4.748 bytes which does not contain any @path@ or @text@ elements.

Comments are welcome.

[1] http://test.rudolphina.org/svg/Plaene/test1/svg-t5-011.xhtml

[2] All the testing was done with Saxon-CE beta 0.1, the @SaxonceDebug@ library using the @?logLevel=FINE@ parameter and Opera 11.61 Build 1250 with memory and disk cache "Off".

[3] For each @subgroup@ container @g@ I've added the number of @path@ elements in the @data-path@ attribute and the accumulated length of the @path data@ in the @data-length@ attribute.


Replies (5)

Please register to reply

RE: Remarks on performance with SVG - Added by Philip Fearon over 8 years ago

Performance measurements will be affected greatly by the browser you're using, any cached files, the hardware platform and any other background processes running on the system.

For example with Internet Explorer 9, I get to (c) in probably about 0.5 seconds - whilst the equivalent using Chrome takes about 10 seconds - this is on an i7 laptop with 4GB RAM.

It seems performance has been improved significantly by using a separate and smaller data file. If you want to speed things up further later it may pay to have a smaller XHTML file and load the additional data in smaller chunks using @ixsl:schedule-action@ and perhaps some UI feedback whilst the data is loading.

With applications, users perceive responsiveness quite differently depending on the amount of feedback supplied and whether they can perform other actions (or cancel the existing task) while a task is being performed.

RE: Remarks on performance with SVG - Added by Manfred Staudinger over 8 years ago

I finaly moved those 601 @text@ elements into a separate xml file (in no namespace)[1]. Instead inserting and deleting the @visibility@ attribute with @ixsl:set-attribute@ and @ixsl:remove-attribute@ I add and delete a @svg:textArea@ by using @xsl:result-document@ with methods @ixsl:append-content@ and @ixsl:replace-content@[2]. This solved the performance problem mentioned above - check it with Opera 11.61!

[1] http://test.rudolphina.org/svg/Plaene/test4/svg-t5-011.xhtml [2] Not exactly: as a workaround for an other problem the @svg:textArea@ element is only emptied and its @id@ attribute deleted.

RE: Remarks on performance with SVG - Added by Manfred Staudinger over 8 years ago

I've uploaded a new version of my architectural drawing [1]. It's a complete rewrite [2]:

  • drop @svg:switch@ for a global boolean [3] in xslt to use @svg:textArea@ in Opera and @svg:text@ for all the others.
  • use @ixsl:schedule-action@ to load the text messages (@svg-t5-011.xml@) and initialize the key
  • delete almost all the svg attributes from the static svg and initialize them at load from @svg-t5-tab.xml@
  • make the drawing adaptive to the window size at load by using @getBBox@ [4] on the outermost @svg:g@.

Comments are welcome.

[1] http://test.rudolphina.org/svg/Plaene/test1/svg-t5-011.xhtml [2] compared to the previous version at http://test.rudolphina.org/svg/Plaene/test4/svg-t5-011.xhtml [3] @ixsl:eval('document.implementation.hasFeature("http://www.w3.org/Graphics/SVG/feature/1.2/#TextFlow", "1.2")')@ [4] @ixsl:eval(concat('document.getElementById("', $svg/g/@id, '").getBBox()'))@

RE: Remarks on performance with SVG - Added by Philip Fearon over 8 years ago

This update, with its gradual loading, gives a much improved user-experience - I like it! It seems much quicker also.

I've tried this on Opera, Firefox, Safari and IE9 browsers. It seems to work properly on all of these, except IE9 - where the drawing is loaded, but the main heading and options table isn't created.

I haven't looked at your XSLT yet, but one minor observation: If you find yourself using ixsl:eval calls frequently it might be worth trying to refactor this so ixsl:eval needs to be called only once, to create a JavaScript function in the global scope. You can then use ixsl:call to access the newly created function. So the JavaScript content of ixsl:eval might look something like:

var getSVGelement = function(svgid) { ... }

You can then make calls to this function using:

... ixsl:call(ixsl:window(), 'getSVGelement', $svgid)

It's worth mentioning also that in Saxonce, the XPath function @fn:id()@ actually uses getElementById for HTML or XHTML pages. For XML documents (not hosted in the browser), this function builds an index of @xml:id@ attributes that can be exploited on further calls.

RE: Remarks on performance with SVG - Added by Manfred Staudinger over 8 years ago

Thanks for your quick answer!

  • new upload for minor changes (see below).
  • for the IE9 issue I would expect a Saxon-CE error message.
  • agreed for avoiding frequent @ixsl:eval@ calls.
  • I cannot get @fn:id()@ working (at least Opera 11.62). I have included an @xml:id@ on each @svg:text@ of @svg-t5-011.xml@ and added a @xsl:message@[1] where it is processed, but @fn:id()@ returns empty.
  • as a minor point, the parser for the stylesheet seems to take the @textArea@ for an HTML element [2] even it is in the (default) SVG namespace.

[1] @<xsl:message select="id($curr-elem/title, doc(concat($file-name-base, '.xml')))/text()"/>@ [2] @Failed attribute on textArea element: x="{round($x)}".@

    (1-5/5)

    Please register to reply