Some ideas about how vispy could make its way into the browser.

Vispy is a Python library for hardware-accelerated visualization. Why would we want to have it working in the browser?

• The IPython notebook: it runs in the browser, and it would be great to have vispy visualizations running in the notebook.
• Fully client-based visualizations would allow static IPython notebooks to embed interactive visualizations.
• Visualizations written in Python could be ported on web applications, which is the place where people are spending more and more time.
• For a lambda user, it is much easier to run a Javascript application than a Python application.
• No more messing around with the OpenGL implementation in the graphics card drivers, WebGL just works! On Windows (Chrome and Firefox), it actually uses DirectX through ANGLE.
• Using HTML/Javascript is the simplest way of porting applications on mobile devices. WebGL begins to be supported on some mobile browsers (including Chrome).

That being said, Python is the primary language of the library and remains the priority number one.

How to make vispy run in the browser? There are several possibilities, grouped into two categories: those where there's a Python server running, and those where the visualizations are written in pure HTML/Javascript and do not require a Python process to run.

The approaches are ordered as follows:

• from hardest to easiest
• from more server-focused to more client-focused

In this approach, the server is responsible for all the rendering. The HTML client just sends user action events to the server, and receives a compressed video stream generated by the server.

• Pros:
  • easiest solution
  • most generic
• Cons:
  • requires a server-side OpenGL backend
  • latency/slow? (requires sufficient bandwidth for the video stream)

Here, the client still sends user actions to the server, but the server sends back OpenGL commands instead of a video feed. The WebGL client processes locally the commands and executes them.

• Pros:
  • no need for the server to have access to an OpenGL renderer
• Cons:
  • need to transfer large amount of data

Here, a given visualization is entirely written or translated in Javascript.

We could have a low-level static representation of a visualization, and a WebGL renderer which would render it just as the Python version would render it. However this implies strong constraints on the architecture, in particular for custom interaction handlers which would need to be rewritten in Javascript anyway.

We could also have a Javascript API which would mimick the Python API, so that porting a Python visualization to Javascript would be easy.

• Pros:
  • no Python backend needed for running the visualization, which enables a broad range of scenarios: integrate an interactive visualization in a static notebook, create web versions of visualizations, etc.
  • probably the fastest solution in terms of performance... but that would require some benchmarks.
• Cons:
  • one or multiple Python layers would need to be converted in Javascript, meaning two implementations of the same code in two different languages. Any update in the code would need to be reflected in the other language. That is painful unless we can find a way to automate this partly.

Here we consider the backend system of vispy and the implementation of a Javascript backend. This obviously requires a Python process running somewhere. Depending on what the backend has access to, it would work with the VNC or Python/WebGL approach.

In summary:

• A browser implementation would have important benefits but would require significant work.
• It is low priority now.
• The easiest solution, which we probably want to have anyway in the long run (that does not prevent to try the others later) is the VNC-like approach. We could take inspiration from Michael Droettboom's work with Matplotlib.

Python <--> Javascript projects:

• PyJS
• PyvaScript
• Brython
• Skulpt