Blog post on Bokeh and Vispy

[Almar Klein]

http://www.almarklein.org/future_vis.html

Looking forward to your thoughts.

- Almar

[Cyrille Rossant]

Hi Almar,

I agree with these ideas. Personally I think the best way moving
forward is to design a compiler architecture in order to support many
languages and frameworks (JavaScript, Python...).

Vulkan may be part of the solution, but that doesn't actually rule out
WebGL. If Vulkan is not supported in the browser, we could find a way
to have a WebGL backend in addition to Vulkan. Same thing for Metal
(Vulkan may not work on Apple computers and devices).

The main challenge is to find an abstraction level that targets
low-level APIs like Vulkan and Metal but also slightly higher-level
APIs like WebGL and OpenGL ES. I've seen some experimental work
towards a SPIR-V-to-GLSL compiler. We could write shaders in any
language that compiles to LLVM. The LLVM bitcode could then be
translated to SPIR-V (Vulkan backend) and GLSL (WebGL backend). I
guess we could even have a CPU backend as a fallback, using
emscripten, llvmpipe, etc.

We would end up with something like a game engine, but for data
visualization. If you think about Unity, it gives you a framework to
create a platform-independent game that you can then compile to
Windows, Linux, OS X, iOS, Android, browser with WebGL, PS3, Xbox,
etc. No reason why we couldn't do something similar for data
visualization!

This is a significant undertaking but I think it is definitely doable
with proper funding and resources...

Cyrille

> --
> You received this message because you are subscribed to the Google Groups
> "vispy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vispy-dev+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vispy-dev/55E807A5.10203%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Almar Klein]

> Vulkan may be part of the solution, but that doesn't actually rule out
> WebGL. If Vulkan is not supported in the browser, we could find a way
> to have a WebGL backend in addition to Vulkan. Same thing for Metal
> (Vulkan may not work on Apple computers and devices).
>
> The main challenge is to find an abstraction level that targets
> low-level APIs like Vulkan and Metal but also slightly higher-level
> APIs like WebGL and OpenGL ES. I've seen some experimental work
> towards a SPIR-V-to-GLSL compiler. We could write shaders in any
> language that compiles to LLVM. The LLVM bitcode could then be
> translated to SPIR-V (Vulkan backend) and GLSL (WebGL backend). I
> guess we could even have a CPU backend as a fallback, using
> emscripten, llvmpipe, etc.

Things would be so much less painful if we could target just one
backend. The targeting of desktop GL + webGL in Vispy seems more than
challenging enough already ...

[Cyrille Rossant]

> Things would be so much less painful if we could target just one backend.
> The targeting of desktop GL + webGL in Vispy seems more than challenging
> enough already ...

Unfortunately I don't think that's possible. The sad truth is that
there is no single backend that fits them all.

In VisPy things are highly challenging because (1) the code has not
been designed for that from the ground up (WebGL is an afterthought)
and (2) OpenGL is getting in our way. Things could be much simpler
with a modular architecture that could potentially target multiple
backends (even if Vulkan or WebGL is the only backend that we
implement first).