Nested Network Image Compression Benchmarks

Currently !NN images are cached as Java BufferedImage objects (in src/ding/view/DGraphView.java) with image width and height set to DEF_SNAPSHOT_SIZE which is 400. Asssuming a pixel size of 4 bytes, this would imply a size per cached image of 640kB. Even at this modest resolution this size can cause serious memory allocation problems when hundreds of nodes contain nested networks! One possible workaround is to cache the images as JPEGs or PNGs. Please note that using JPEGs does not necessarily imply lossy compression! Below are the results of a few experiments using this idea. (The compression factors have been determined by instrumenting the convertToCompressedImage() method in !DGraphView and assuming that the uncompressed image size is 640kB.)

This seems to indicate that we should probably generate PNG images rather than JPEGs.

Below we are comparing rendering using BufferedImage caching, i.e. using the original strategy, vs. PNG caching. Please note that this is only the overall time spent creating TexturePaints and nothing else. In other words it is not the overall time for rendering!

This shows that in the worst case, the PNG caching strategy adds just under 3s to the overall rendering time. While this seems a lot, it has to be weighed against the much smaller overall memory footprint which for large numbers of nested networks can easily be an order of magnitude lower than when caching BufferedImage objects.

Note: A further speedup is conceivable: We could try to run-length encode (RLE) raw BufferedImage data. This would probably be very fast and add much lower overhead than PNG images but would require testing across platforms since we have no idea what the internal data representation of a BufferedImage is. It is likely though to consist of 4-byte pixels which makes RLE compression based on Java int arrays a tempting strategy.