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

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
>