[Roadmap] WGLMakie

[SimonDanisch]

Serverless visualization

JSServe + WGLMakie already work pretty well with a running Julia server, but this doesn't scale very well to serve interactive demos for thousands of people (e.g. blogpost/articles). For that we need to Move more work into the browser on the clients computer and make it easier to remove any communication with Julia.

Move more to JS

• Rewrite 2D camera & axis in JS and others
• Make it easier to overload event callbacks and recipes in the backend (ties into new api for plotobjects)
• Move Tyler to JS (needs better event + plotobject api)
• Datashader in JS + WebGL
• More of the drawing & updating API in JS
• Datainspector in JS

WASM integration

• more of a future pathway, but toy examples are already possible
• make sure JSServe is ready for it, by e.g. enabling:

statically_compilable_julia_func(args...) = ...

js"""
js_args = [...] // from julia or directly js
const result = $(statically_compilable_julia_func)(args)
update_plot(plot, result)
"""

Or another possible API:

using WGLMakie, JSServe,
obs = WASMObservable(data)
data = lift(statically_compilable_julia_func, obs)
plot(data)

Compsoable GUI elements

• playbutton for anything playable
• drawing over every plot
• drag & drop
• More predefined UI elements for dashboards (especially layouts)
• complex recipes including sliders and interactions and composable UI elements

Declarative API for Pluto & AoG and easier animation

Right now one animates in Makie like this:

arg1 = Observable(...)
arg2 = Observable(...)
attribute1 = Observable(...)

# only call plot one time!
plot(arg1, arg2; attribute1=attribute1)

This is highly performant, but is difficult for complex dashboards where data can change the plot types or attribute passed (e.g. like in AoG).
This kind of mutating API using observables and just one plot call is also working against Plutos way of animating, which executes the complete cell defining the plot on every change.
So we need a declarative API like this:

arg1 = Observable(...)
arg2 = Observable(...)
attribute1 = Observable(...)
plot_spec = lift(arg1, arg2, attribute1) do arg1, arg2, attribute1
    if attribute1 == something
        return Scatter(arg1, arg2, marker=attribute1)
    else
        return Lines(arg1, arg2, color=attribute1)
    end
end

Rendering the plot_spec efficiently with diffing will be the basis for a much more performant Pluto integration and easier to write dashboards.
Prototype exists here: #2868

Test & Polish

• Feature parity with GLMakie
• Better docs for deploy, server setup, dashboards, animations etc
• performance improvements (unintuitively also improved by moving more to JS, because usually data transfers are the bottleneck)

More backends

• Ray tracing via THREE.js-PathTracing-Renderer
• Canvas backend similar to CairoMakie but with JS (for faster load times and higher quality 2D rendering, and 100% browser compat)

[j-fu]

Will it be possible then to use WGLMakie in Pluto without JSServe ?

[SimonDanisch]

No... what would be the use case?

[SimonDanisch]

More precisely: what's the use case that isn't covered by a better JSServe pluto integration?

[j-fu]

Besides of feeling "non-plutonic", essentially this...

I am not sure how fast Julia->JS data transfer with JSServe is and how it is done. If it uses ASCII encoding I think that Pluto's publish_to_js would be faster.

[SimonDanisch]

It should be as fast as possible and quite similar to Plutos protocol ;)
It may even be faster, since I integrated some MsgPack improvements, that Pluto doesn't have yet...
We did want to start sharing the protocol between Pluto & JSServe, but neither @fonsp nor me have had time to push it any further. But we did create the package and put some initial code in it :D