snogglethorpe/snogray — Issue #21: Make output/recovery framework more flexible
Author: snogglethorpe
Created: 2012-02-19 23:06:34+00:00
State: open

Currently the code is structure pretty firmly around the idea of line-by-line output, with the output file being opened before rendering and rendering being done line-by-line. The recovery system also assumes this.

However some types of rendering do not fit this model well, because they don't proceed line-by-line (for instance, metropolis light-transport).

It would be nice to have a more general structure that _supports_ line-by-line output (as it's kind of nice to see the output as it is computed), but also allows other patterns, particularly those that write the whole image at once. The recovery system would need to be more complicated for this case, but it could still do "snapshots".

As a snapshot-based system wouldn't have the ability to determine rendering progress by counting the number of image-lines that were written, a secondary "checkpoint" file would be required to record the rendering progress so that recovery could resume at the appropriate point. Such a checkpoint file would be nice for other reasons too; for instance, it could record the entire rendering parameter set, allowing the user to just say "`snogray --recover foo.jpg.snogcheck`" instead of having to give the entire command-line again (which they may not remember, and if the machine crashed, there may be no record!).

The checkpoint files can use json format, which is really easy to do, especially after the driver layer is rewritten in Lua.