Deephaven express should respect the disable webGL flag

[mofojed]

We're adding a flag to disable WebGL: deephaven/web-client-ui#2134
Deephaven express should respect that flag.

[mofojed]

We'll need the client to communicate with the server plugin whenever the WebGL setting changes (and likely theme as well for colors to work correctly). That gets a little complicated because we only have message streams to specific instances of widgets, whereas this would be a "global" setting. Probably easiest to just communicate with each instance, but in theory we could "optimize" it to only notify once per session and have that somehow propagate to each instance (just for that user/session). Otherwise you may have a bunch of plots open, and send the same message "webGL=off" to each instance.

[mattrunyon]

I don't think the client necessarily needs to communicate to the server here. We could just replace any series ending in gl with their non-gl variant in JS even if the server says to render with gl

[jnumainville]

This is a little more complicated than I initially thought
From https://plotly.com/python/webgl-vs-svg/

The following trace types use WebGL for part or all of the rendering:
Accelerated versions of SVG trace types: scattergl, scatterpolargl, heatmapgl
High-performance multidimensional trace types: splom, or parcoords
3-d trace types scatter3d, surface, mesh3d, cone, streamtube
Mapbox Gl JS-powered trace types: scattermapbox, choroplethmapbox, densitymapbox

So we definitely would swap out the gl versions to the svg versions, but what do we do in the other cases? Do we disable those too by just removing them and showing a message that they are not supported when WebGL is disabled?

[mattrunyon]

That's a good question. This is probably something that we could handle client-side if that's easier. There's already some checks for 3D/geo at least based on trace names (so ticking data doesn't reset you when rotating the scene).

It should be easy to replace traces client side with their non-gl variant since we just need to strip the gl suffix. Then for those other types we can determine what to do. Maybe disable with a button to enable just that plot if webgl is the only option

[jnumainville]

We'll definitely do this client side. My inclination would be to disable with a button to enable unless web.webgl.editable is false, then it's just disabled with no option to enable. That's perhaps the strictest version of what is reasonable, but without finer grained settings it seems like the only option that obeys the setting whilst allowing as much flexibility as possible.