[IPython-dev] Interactive Matplotlib in the browser

[Brian Granger]

On Thu, Oct 11, 2012 at 11:39 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> On 10/11/12 10:45 PM, Brian Granger wrote:
>> It is not clear to me that the stream of PNGs will win in the end.
>
> What do you see as alternatives?  Reimplementing matplotlib in the
> browser?  SVG-based rendering, where we send over a complete svg image
> at each step (or just the changed svd elements)?  I'm curious what other
> ideas you have.

There are two cases:

* Small data sets and relatively simple plots types.  For these, I do
think it makes sense to send the raw JSON data to the browser and
implement a Javascript based plotting library that consumes the JSON
and has an extremely high level of interactivity.  I don't think we
need to do *all* possible plot types with the pixel perfection,
embedded math, infinite configurability.  When people are working
interactively they want: i) plots that look spectacular - pixelized
images don't cut it and ii) high levels of interactivity.
I am not suggesting that we reimplement all of Matplotlib.

Keep in mind that current situation with Matplotlib and the IPython
Notebook is not very ideal.  The pngs that are the default don't look
that great and svg is not yet good enough to use as the default.  We
really do need in browser plotting that *looks* better.

Another important aspect of the JSON data approach.  We want to enable
Notebooks to be viewed and used in contexts outside the actual
notebook interface (nbviewer for example) where there is *no* python
code that is run.  Because we save the JSON data in the notebook, JSON
based plotting can be done interactively in contexts like nbviewer.
For sharing computational results with a wide audience that is
critical.

* Large data sets

I don't really have any alternatives - this is simply a really hard
problem.  In some contexts downsampling is possible.  In other
contexts it is possible to stream subsets of JSON data at are required
for the current view.  It is my impression that the folks at Continuum
are working on this problem.  Maybe they have some insight into this
problem.


>
> If
>> you make a single static plot of a large data set, that is way better
>> than trying to send the data to the browser and rendering it there.
>> But if you have to send hundreds or thousands of PNGs to get
>> interactivity, that benefit may be washed out.  Especially if you have
>> multiple users interacting with plots - the server could quickly grind
>> to a halt.  I think we should do tests to see how bad it gets, taking
>> into account the multiple user question.  The one performance benefit
>> that I can think of is that you can tune the level of interactivity to
>> limit the data that comes back.  For large data sets, users might be
>> willing to settle for less interactivity.  That option doesn't exist
>> when you send all the data back.
>
> I implemented server-side rate-limiting (see my most recent
> modifications at https://gist.github.com/3875846, for example).  Or are
> you saying that the server might not be able to render pngs for hundreds
> or thousands of users?  I wonder if we can get a better protocol than
> just a "Motion PNG" [1].
>
> A disappointing thing is that it seems to take about 100ms to render the
> example png image; it would sure be nice if that was a lot faster.
>
>
> [1] http://en.wikipedia.org/wiki/Motion_JPEG
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com