[IPython-dev] Interactive visualization in the IPython notebook 2.0
Jason Grout
jason-sage at creativetrax.com
Thu Apr 3 13:38:51 EDT 2014
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
>
More information about the IPython-dev
mailing list