Storyline Suspend Data Compression

No, we have not experienced any sort of slide-to-slide delay due to compression.  More often, there will be a delay due to fetching the assets for the next slide (you will experience the three loading dots when this occurs).

A couple of notes on compression:

• The compression algorithm being used is called deflate, which is a hybrid of Lempel-Ziv 1977 (LZ77) and Huffman encoding.  https://en.wikipedia.org/wiki/Zlib
• The pako package implements and optimizes this algorithm directly in pure Javascript.  Information on this implementation, the source code, and some performance metrics can be found on their github page: https://github.com/nodeca/pako
• Today's processors (even in cell phones) are so ridiculously advanced compared to the processors available when these algorithms were first developed and highly optimized. It's just not even funny.
• The amount of data we are talking about in this scenario, even when it's on the larger size of say 64kb, is still so ridiculously small compared to what these algorithms are typically being used for nowadays.
• The pako page mentions benchmarks of deflate-pako running at around ~10mb/sec, and inflate-pako running at ~130mb/sec.   Based on that benchmark, compressing (deflating) a mere 64kb would take ~6.1 milliseconds!  I highly doubt anyone on this planet would actually notice 6 milliseconds. 🤔

So, I really don't think you will see any perceived delay.   We certainly have not ourselves nor received any reports that are attributable to the compression.