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

Cyrille Rossant cyrille.rossant at gmail.com
Thu Apr 3 13:22:53 EDT 2014

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

More information about the IPython-dev mailing list