Performance and TypeScript

[neurolabusc]

Inspired by @nx10 NIfTI acceleration, we can improve performance and reduce dependencies by replacing fflate with the new compression streams API. By moving to TypeScript, we can maintain compatibility with NiiVue while still compiling to pure JavaScript. At the moment, the new code is on a separate fork, but it can be merged soon.

Since TRX is based on the Zip format (not just deflate or gzip), I adapted @ndesmic's zip class using compression streams. I extended that minimal example adding support for zip64 formats as well as zip files that use data descriptors rather than explicitly reporting compressed size (I think this was mainly for tape drives, where random access was problematic).

I also optimized the TRX code, so even the uncompressed TRX files are accelerated.

Using compression streams is somewhat faster on node (as shown below). However, it appears to be dramatically faster on the Google chrome browser (x2).

Old node performance:

IFOF_L.tt.gz	Size	17564621	Time	7214
IFOF_L32z.trx	Size	68392480	Time	7346
IFOF_L16z.trx	Size	56518628	Time	7302
IFOF_L.tt	Size	34713543	Time	4701
IFOF_L.vtk	Size	263300470	Time	1733
IFOF_L.trk	Size	137369684	Time	1420
IFOF_L.tck	Size	137615752	Time	973
IFOF_L16.trx	Size	68746591	Time	718
IFOF_L32.trx	Size	137369221	Time	472

New node performance:

IFOF_L.tt.gz	Size	16547280	Time	5793
IFOF_L32z.trx	Size	68392480	Time	4552
IFOF_L16z.trx	Size	56518628	Time	3175
IFOF_L.tt	Size	34713543	Time	5005
IFOF_L.vtk	Size	263300470	Time	1408
IFOF_L.trk	Size	137369684	Time	1288
IFOF_L.tck	Size	137615752	Time	843
IFOF_L16.trx	Size	68746591	Time	670
IFOF_L32.trx	Size	137369221	Time	317

[neurolabusc]

I implemented an optimization to @frankyeh's TinyTrack format. It turns out that most of the time was spent applying the 4x4 spatial transform. We can inline this instead of calling transformMat4 and do 9 instead of 12 mults because affines are homogeneous coordinates (the same reason the NIfTI sform saves 3x4 of the 4x4 matrix).

TRX is great because it provides lots of features (per vertex, per group and per streamline properties) and allows flexibility in precision. TRX is dramatically smaller and faster than the other lossless measures. TT is a little lossy, but provides small files with reasonable load times. The next step is to include @haehn's TRAKO which should be much more compact, with a trade off in precision and speed.

[frankyeh]

great implementation! very informative comparison.