Trash. WebBackend

Some quick notes about how we could implement a web backend.

There are two broad methods:

• Offline method. There's a pure HTML/Javascript document containing a standalone interactive visualization application.
• Online method. There's a Python server running with VisPy, and a browser communicating with it (using e.g. WebSockets).

Offline method

Main advantage: no need for a server: possibility to share a standalone document. Main disadvantage: very hard to implement (for now)

A visualization application would be written in Python on top of VisPy. There would be some code generation procedure that would port the whole application in Javascript, using a VisPy.js library. The VisPy library would know which GL commands to send when some user event happens (e.g. mouse move) so that it could compile code to instruct WebGL to do just that.

The main difficulty is that VisPy is coded in Python whereas a browser only accepts Javascript.

This method is not preferred at this time, but may be in a few years when browsers will accept Javascript (this is slowly beginning to happen).

Online method

This is basically the route chosen by Matplotlib with the IPython notebook. We should seriously look at how they do it. We may also want to wait for IPython to implement their Javascript API as it might be relevant here. It will basically provide a framework for real-time Python-Javascript communication.

The pipeline is:

User interaction ==> Javascript ==> Sockets ==> VisPy ==> GL commands ==> Sockets ==> Javascript ==> WebGL rendering

The VisPy could receive user events, and output GL commands to send to OpenGL. We would need a clean messaging protocol API (JSON-based? also, see IPython) to serialize those commands, send them through sockets to the browser, and let WebGL execute those.

Note the similarity with the offline approach. We may need to think about a nice abstract and general way of representing the "user events ==> GL commands" transformation in VisPy.

There's also a difference with Matplotlib where the rendering happens on the Python side. The drawback is the bandwith: a bitmap image needs to be sent at every time step, which is slow. I'm not sure about the performance of the Web backend in Matplotlib at this point. A sophisticated compression method (based on successive image differences?) might help.

With the method described here, only a small amount of information needs to be sent back and forth between Python and Javascript: the user events on one end (e.g. delta mouse position, etc.), and a small GL command on the other end (e.g. only glUniform for zooming/panning in a plot, as there's no need to update the data in general). Both bandwith and latency should be satisfying.

What's more, the Python server could run on a different machine which would not need OpenGL (e.g. headless server). The rendering would only occur client-side. This could also enable multi-user scenarios.