[IPython-dev] Fwd: notebook plots via javascript

[John Hunter]

On Mon, Jun 4, 2012 at 8:00 AM, Zoltán Vörös <zvoros at gmail.com> wrote:

> As for the place of the backend, I have read somewhere that matplotlib wants
> to do away with the plethora of backends, so I didn't even consider raising
> the issue there. Moreover, if we embark on implementing the backend
> "in-house", it could be implemented in a way that most suits ipython.

While we are definitely interested in reducing the number of backends
(eg native wx rendering) we are very interested in javascript in mpl,
primarily because there is such a compelling use case for it in the
notebook.

On the issue of interaction (pan/zoom/add or remove line) in the
notebook.  While I appreciate that there is value in
what-you-see-is-what-you-get vis-a-vis code in the notebook vs the
saved figure, I don't think it is our job to overly limit what the
user does.  Persistence is only one thing notebooks are good for,
others will use them as an interactive scratch pad, and interacting
with the figure in all sorts of ways is useful.  After they have
played around and want to persist the notebook, they always have the
option of re-running the cell to restore the original generated code
sans interaction.  I think it best to give people the maximally useful
thing, and let them make the right decisions about how they want to
use it.

In that vein, if you try to add rich interactions in a javascript
backend, I do think you will hit a wall at some point because the
backends are fairly dumbed down in mpl.  They are mostly a collection
of geometric primitives in display coordinates.  Eg, the axis tick
doesn't know it is part of the axis at the backend level, so
implementing interactive navigation might be challenging without
client/server cross-talk.

Another approach might be to not implement a backend at all, but a
matplotlib.figure.Figure persistence mechanism that outputs javascript
code.  Eg, if you hi-jacked the Figure.draw method, you might be able
to output more intelligent javascript because you would know "this is
the figure, this is the axes, this is the axis" and would have a
better view of the transformations, etc.  Just a thought about an
alternative approach.  We are also open to modifying the mpl
middle-ware to pass you more information as needed to the backend to
make sure you have what you need at the backend level.  Eg, we already
have the open_group/close_group methods, motivated by SVG to define
clickable groups (suppose you want to change the font of all the
ticklabels in inkscape), and we could extend this concept to pass
additional meta-data through.  Eg, the Axis open_group call could pass
"self" through if you wanted to grab some of the data from the
instance you were rendering.

I have been concerned for some time that the need for interactive
javascript plotting in the notebook would push efforts into yet
another plotting library, and hence fragment community resources.  If
we can get the job done in mpl, I would be very happy, and I'm sure we
can come up with some resources on our end to help you.

Thanks!
JDH