Fix to make identical bundles on different nodes

[archmoj]

Possibly since v.1.36.1 a random number was attached to one of the GLSL variables of shader programs used in gl-line3d module e.g. encode_float_1540259130(pixelArcLength) resulting in non-deterministic bundles as reported in https://github.com/plotly/streambed/issues/13816.

This PR fixes this issue by removing one linking step within gl-line3d module.

@plotly/plotly_js
cc: @nicolaskruchten@dmt0@tarzzz

[etpinard]

So, if I understand correctly, browserify + glslify currently bundles the encode_float function with some additional hash (e.g. encode_float_1540259130 or encode_float_1604150559) leading to bundles with potentially different checksum output. @archmoj is this correct?

If so, what's special about the shader program in glsl-read-float? Why don't other glsl packages exhibit this behaviour? Shouldn't we instead try to solve this problem at the glslify-level? Maybe we can set a flag that makes the additional hash reproducible?

[archmoj]

So, if I understand correctly, browserify + glslify currently bundles the encode_float function with some additional hash (e.g. encode_float_1540259130 or encode_float_1604150559) leading to bundles with potentially different checksum output. @archmoj is this correct?

Correct.

[archmoj]

If so, what's special about the shader program in glsl-read-float? Why don't other glsl packages exhibit this behaviour?

gl-line3d is the only module that uses glsl-read-float module. And there is a linking problem between glsl-read-float and gl-line3d due to casting doubles to shorts between two shaders on different hardware.

[archmoj]

Shouldn't we instead try to solve this problem at the glslify-level?

We could. But that require spending more time debugging.
I suggest we open an issue on gl-line3d or glsl-read-float when/if this PR merged.

[etpinard]

I suggest we open an issue on gl-line3d or glsl-read-float when/if this PR merged.

yep, good idea.

[etpinard]

💃