ParaView Remote Interactivity Issues

Summary
We investigated complaints of poor interactivity when ParaView was run remotely between the user's home and the LANL cluster called Lobo[1]. We successfully reproduced the loss of interactivity running ParaView between a home system and Lobo by adding visual elements to the rendered scene. Initially interactivity was fine, however as visual elements were added we experienced the loss of interactivity. We determined that the loss of interactivity was independent of input data set and data set size and was not linked to a specific visualisation technique which enabled us to reproduce on UCSD cluster called Nashi using ParaView's internal sources and test recording mechanism. By instrumenting the ParaView client server image delivery sub system we confirmed that frame rates dropped dramatically as as visual elements were added into the scene. We have identified the compression scheme employed by the image delivery subsystem at the root of the remote interactivity issues. ParaView's image delivery subsystem employs a run length encoding scheme developed by Sandia labs called "Squirt". Like all run length encoding schemes Squirt is fast but doesn't deliver high compression ratios. We found that the compression ratio degraded quickly as visual elements were added into the scene. We compared Squirt compression scheme against two popular compression schemes, zlib which is used in the linux gzip tool, and szip which is employed in HDF5 library. The tests show that, at its highest setting, zlib's compression ratio's are an order of magnitude higher than Squirt's across the board, however run time is also an order of magnitude slower. However, benchmarks show that ParaView's frame rates are also an order of magnitude longer than the run times, so run time is not a significant factor here. In order to confirm the result we implemented a second suite of in-situ tests implementing zlib compression in ParaView such that when Squirt was turned off, zlib was turned on. This enabled us to benchmark ParaView suing both Squirt and Zlib side by side on real test data. The results show that in the cases where Squirt's frame rates diminish to non interactive rates, using zlib produces a speed up of a factor of 4.39 which, although modest, provides significantly better interactivity with image delivery times dropping from from on average 5.25 seconds down to 1.19 seconds per frame.

A Benchmark of Squirt and Zlib Compression in ParaView
For this suite of tests we implemented zlib compression in ParaView so that a side by side comparsion of zlib and Squirt could be made under real world conditions. In these in-situ tests we seek to isolate the the compression scheme as much as possible and to stress test the algorithms in a worst case scenario. To this end in the render-server configuration dialog (Edit->Settings...->Render View->{General,Server}) we set the Remote Render Threshold to 0, disabled Image sub-sampling and set the LOD Threshold to 0. We set the Squirt compressor to loss-less mode at 24 bpp and zlib compressor to its highest setting which is also its slowest. The results summarised in the following table and histogram. For each scheme two renderings were used. The first is an outline of a two dimensional dataset. This rendering has large areas of uniform color and compresses well with both Squirt and Zlib resulting in interactive frame rates for both. The second rendering of a fractal image has a lot of color variation and is used to confound the compression schemes. It represents a worst case input that will cause Squirt compression ration to fall so low that frame rates are not interactive. In this case Squirt compression ratio drops dramatically to 2.9 and frame rates fall below interactive rates, with each frame taking on average 5.25 seconds. Zlib on the other hand delivers a 16.06 times higher compression ratio than Squirt resulting in a 4.39 times faster frame delivery rate. The speed up factor of 4.39 is a modest improvement, however zlib's average delivery rate of 1.2 seconds per frame is a significant improvement in interactivity over Squirts average delivery of 5.25 seconds per frame.

Input Datasets
The following images are screen shots taken from ParaView during the tests. We used a saved state file to insure the same initial conditions and a automated test script generated using ParaView's Tools->record Test feature to insure reproducability.

A General Comparison of Loss-less Compression Schemes on Images rendered by ParaView
The following table sumarises the test sequence we implemented to compare Squirt the current compression algorithm used in ParaView to two potential alternatives, szip and zlib. Each scheme was tested using various compression levels. Two passes were made over each input image. The first pass the full 24 bit BMP was processed. In the second pass, Squirts level 5 color reduction algorithm was applied. This results in 10 bit color data. The reduced color data was then used as input to each of the schemes. We did this to show case Squirt at its best and to level the playing field accounting for the fact that the other schemes tested were loss-less. The purpose of the tests were to compare Squirt to various alternatives, there for we used Squirt's timing and compressed data size as a basis for relative comparisons. Collumns Relative Time Delta and Relative Compression Ratio contain the primary results, while other columns contain the raw data.

Squirt is a run length encoding(RLE) scheme and can be set to loss-less or lossy compression. Squirt's lossy compression uses a color depth reduction technique to increase run length. Squirt's strong point is its speed, of the schemes tested it was the fastest. It's weakness is that it achieves a relatively low compression ratio. Szip is a scheme available by HDF4 and HDF5 and patented by NASA. Our tests show that for typical images rendered by paraView szip does relatively poorly compared to Squirt and Zlib. However it is intersting to note that on most challenging input used in the tests szip performs reasonably well. Zlib is public domain implementation of deflate the scheme originally used in pkzip, has fixed memory requirements independent of input data size, and essentially never inflates data. At its highest setting zlib achieved the highest compression ratios an order of magnitude higher than Squirt for all test inputs. The trade off, is as is often the case, speed as runtime for zlib compressor is an order of magnitude longer than Squirt. However our in-situ benchmarks show that compressor run time does not contribute significantly to frame rate. Decreasing the color depth of the input images further increased the compression ratio and the run time for the zlib compressor. The results suggest that it will likely be worth while to pre-process rendered images by reducing the color depth much as is done for Squirt in typical use.

Input Datasets
The fololwing images were used as comand line parameters to our test code.

Special Thanks
Thanks to William Daughton of LANL for help identifying and reproducing the issue.