Closed mix3d closed 5 years ago
I think it is related to byte alignment when decoding and how vue on Typed array are managed across the browser. My guess is that we need to do something like that
Interesting that it is indeed vue specific... since the other examples work fine. Hmm!
By Vue, I don't mean vue.js but a view of a TypedArray like
const bytes = new Uint8Array(...);
const float = new Float32Array(bytes, 3, 10); // <-- this is a vue of the data
I think this is a case of the received arraybuffer length not being a mutiple of your dataset datatype (which I see is Uint16). Is your dataset size is a multiple of 2?
It works on other browsers though. It even fails on the same volume used on all the vtk.js examples (https://github.com/Kitware/vtk-js/tree/master/Data/volume/headsq.vti)
This looks like a bug in Firefox. The netlify server is sending Content-Encoding: gzip
, but firefox isn't decoding the data as it should be doing. If you pop into the debugger and check out the data, firefox is giving you the gzipped version of "0edblahblahblah.gz" (so two gzip layers). I think this is the relevant bug report for firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1269101
I have a PoC demonstrating this issue. Chrome works just fine, but firefox fails to decompress when the received content has MIME gzip and the Content-Encoding is gzip. There also seems to be a size trigger, where datasets under 500 or so bytes will decompress just fine.
What a bummer of an issue. Not VTK though, so we can close the bug.
Firefox v68 (Mac) and v67 (Windows) are failing to load .vti files with HttpDataAccessHelper, with the following message:
The same files work fine on Chrome, Safari, and Edge.
Example: https://vue-vtkjs-viewport.netlify.com/#/example/basic