There is no "flush" API call that would guarantee that any scanlines or tiles already sent to IlmImf are actually written to the file. It does seem to write scanlines immediately when no compression is used, but for "zips" (which is supposed to compress each scanline individually), that also should be possible, and for tiles as well (for any compression, because the compression state doesn't span multiple tiles).
There are cases where it might be helpful to have explicit control over flush. An example would be an app that might be terminated by a controlling process, but you nonetheless want the partially-written file to be as up to date as possible so the process can be relaunched and more or less pick up where it left off. Anybody else run into this or have suggestions? Is there a way to force a flush that I have not noticed? -- Larry Gritz l...@larrygritz.com _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
