[IPython-dev] SVG figures status report

[Bob McElrath]

I thought I'd give a status report on using SVG figures in IPython.

It seems for reason of visual appearance, PNG was chosen as a default.  This can
be circumvented by appropriately choosing figure.figsize.  The reason for the
aliasing at some choices (including the default PNG size) is still unknown to
me.  My best guess is that it has to do with rounding of internal pt
coordinates to pixels (and not to do with the display mechanism -- such jaggy
figures appear jaggy in Chrome, Firefox, and Inkscape).

SVG figures involve a lot of elements, added to the same DOM as the rest of the
page.  The result of this is that by the time you have ~20 figures in one
notebook, the page is perceivably slow.  Scrolling, clicking, editing are all
noticeably slow and difficult.  Page load times increase substantially and cause
browser timeouts.  The ultimate reason for this is simply the large DOM.  This
is true both in Firefox and Chrome (mozilla/webkit).

It turns out this is well known, and a target of SVG 2.0 discussions:
    http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM 
But I would not be surprised that even with a bunch of SVG 2.0 improvements, a
worksheet with many figures would still be intolerably slow.  One can find many
speed-related SVG bugs on Mozilla's bugzilla as well as Chrome.  It seems both
SVG implementations are not nearly as heavily optimized as HTML, and may involve
many O(n) or worse algorithms.  I have noticed that simply having other SVG
elements on the page seems to slow down the operations on any ONE of them (I
perceive the slowdown to be linear).  Likewise adding the (n+1)'th SVG is slower
than adding the n'th SVG to the worksheet.  Something here is linear in time.

Therefore, I think SVG as the default figure format is not an option now, or in
the foreseeable future, and SVG as an option should be discouraged.

However, there are probably some clever optimizations that could be performed to
retain worksheet interactivity in the presence of many figures.  For instance,
each SVG figure could be cached as a PNG or Canvas element.  This reduces the
number of elements in the DOM, and the SVG figure could be stored as a string.
If the user wishes to interact with the figure (clicks on it) we could replace
the bitmap PNG/Canvas element with the SVG.  This way there would be no more
than one SVG in the DOM at a given time.

I believe it is possible that some of the slowdowns I see are due to some
unrelated code in the worksheet (such as if jQuery handlers were attached to
every SVG node).  If this is the case, it will also show up also in notebooks
with no SVG. (see issue #1975)

Maybe people already knew all this, but I thought I'd share my findings, because
I wanted to use SVG instead.

Related: issues #1881, #1975, PR #1881.

--
Cheers, Bob McElrath