[IPython-dev] Interactive visualization in the IPython notebook 2.0

Brian Granger ellisonbg at gmail.com
Thu Apr 3 17:37:59 EDT 2014

For this usage case I would definitely build a Widget, rather than
building directly on top of the Comm layer. The reason is that Widgets
are composible objects that can be hooked together and reused in
different ways. If you using the Comm layer alone, your stuff won't
play at all with existing Widgets and you will have to reinvent a lot
of the Widget stuff yourself.

On Thu, Apr 3, 2014 at 10:38 AM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> I think it depends on how you think about your communication.  If your
> thinking is data/state-oriented, the widget infrastructure makes a lot
> of sense (you just set data values, and the widget infrastructure takes
> care of syncing those values).  If your thinking is function-oriented,
> then the lower-level Comm framework may work better---it's leaner and
> doesn't have a lot of fluff.
> For pythreejs, since we are basically providing proxy objects, it made a
> lot of sense to adopt a state-oriented view and just sync all the
> objects' states back and forth.
> Thanks,
> Jason
> On 4/3/14, 12:22, Cyrille Rossant wrote:
>> Thanks, pythreejs look cool! Now I'm wondering whether we should use
>> comms or the higher-level widgets API for our use-case...
>> 2014-04-03 18:40 GMT+02:00 Jason Grout <jason-sage at creativetrax.com>:
>>> I should also mention that we have been working on wrapping three.js as
>>> a widget, which may be much closer to your usecase than the matplotlib
>>> work.  I think we're nearly done (our main TODO now is wrapping
>>> interactive picking, and then cleaning up the existing code based on the
>>> patterns we've observed, plus documenting and providing examples).
>>> https://github.com/jasongrout/pythreejs
>>> Live demo of your face on a sphere:
>>> http://sagecell.sagemath.org/?q=qjjurl (you may need to press Evaluate
>>> to overcome the latency of loading the javascript, and you'll also need
>>> to grant the browser permission to use your camera)
>>> The idea behind wrapping three.js is that it provides useful scenegraph
>>> primitives, and also renders to canvas if webgl isn't available.  We
>>> basically are just providing access to the three.js primitives in
>>> Python, along with a few convenience classes (for example, for rendering
>>> a function surface, or rendering a text sprite).  We are also building a
>>> converter for Sage graphics on top of this wrapping.
>>> It sounds like vispy needs a lower layer than our pythree.js project
>>> (since it looks like you are constructing the opengl code directly).
>>> But it might give you some ideas...
>>> Thanks,
>>> Jason
>>> On 4/3/14, 8:13, Phil Elson wrote:
>>>> I'm not aware of IPython providing anything other than the generic (and
>>>> useful) infrastructure for this plotting usecase, but there exists a
>>>> comm based proof-of-concept interactive visualisation produced by Jason
>>>> Grout in https://github.com/matplotlib/matplotlib/pull/2524 which may be
>>>> of interest.
>>>> It is also worth noting that the WebAgg backend in matplotlib is a fully
>>>> bona fide backend available since v1.3.
>>>> Essentially the only reason there isn't an interactive matplotlib
>>>> IPython interface already is because nobody with the right technical
>>>> expertise has had an opportunity to do - I don't believe there are any
>>>> remaining technical hurdles, and I don't even think it is a big piece of
>>>> work at this point.
>>>> HTH,
>>>> Phil
>>>> On 3 April 2014 10:47, Cyrille Rossant <cyrille.rossant at gmail.com
>>>> <mailto:cyrille.rossant at gmail.com>> wrote:
>>>>      Dear IPython developers,
>>>>      Let me introduce you to Mustafa Kaptan (in CC), a student who has
>>>>      started to contribute to Vispy [1], and who has made an application to
>>>>      GSoC this year. He'd be interested in integrating Vispy in the IPython
>>>>      notebook for high-performance interactive visualization in the
>>>>      browser. He already made a nice proof of concept [2]. We're likely to
>>>>      need your help soon enough!
>>>>      There are many different and complementary approaches. For now, we've
>>>>      chosen to start with the simplest approach: the server renders a
>>>>      figure with OpenGL, outputs a PNG, and sends it to the browser with
>>>>      WebSockets and Tornado. Javascript captures user actions (mouse
>>>>      clicks, mouse moves, keystrokes...) and sends them in return to the
>>>>      server. I think that is similar to a proof of concept for matplotlib
>>>>      made by Michael Droettboom some time ago [3].
>>>>      IPython 2.0 now offers the right architecture for this. I was
>>>>      wondering whether there was anyone on your side working on something
>>>>      like this already? I think it would make sense to have common
>>>>      protocols, interfaces and code for matplotlib, Vispy, and other
>>>>      visualization libraries. Sending PNG and user events in JSON, creating
>>>>      a sort of "distributed" event loop, all seem generic enough to me. It
>>>>      would be too bad if we all duplicated our efforts for the same thing.
>>>>      Where should we start? Comms, something else? Also, we'd like to reuse
>>>>      some of this architecture for a slightly different approach. Instead
>>>>      of letting the server render the figure with OpenGL, we'd just send
>>>>      OpenGL commands and binary data to the browser (client-side rendering
>>>>      with WebGL).
>>>>      Best regards,
>>>>      Cyrille
>>>>      [1] http://vispy.org/
>>>>      [2]
>>>>      https://github.com/mfkaptan/experimental/tree/master/online_backend/tornado
>>>>      [3]
>>>>      http://mdboom.github.io/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>>>>      _______________________________________________
>>>>      IPython-dev mailing list
>>>>      IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>>>>      http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> 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

More information about the IPython-dev mailing list