Added shared memory option for the render buffer

[leozide]

This change adds the +SM command line option, which tells POV-Ray to use a memory mapped file to back the rendering buffer in vfeDisplay. This way other applications can also map the same file and read from the buffer as its being filled.

I've made this change so that my application (www.leocad.org) can export a .pov file, call the POV-Ray console version and show the rendering progress in its own window (like the Windows version of POV-RAY).

Tested with 3.7.1 on Windows and macOS and it works without any issues. This is my first time changing the POV-Ray source so please let me know if there's anything you'd like me to change.

[c-lipka]

.Be advised that the VFE module you're using as a hook is not part of the portable portion of POV-Ray. Instead, it is an optional helper module to simplify interfacing a GUI to the official interface, which is POVMS. While it so happens that currently all official incarnations of POV-Ray make use of this module, there is no guarantee that it will be present in future or inofficial incarnations..

Probably a better place to hook into is the back-end image buffer used to assemble the image prior to generating the output file. The code is located in the source/base/image/image.cpp directory. It already features a code path to switch to an alternative image buffer; look for FileRGBFTImage.

---

Edit by chris20: the above statement regarding VFE is incorrect, see my later comment in this pull request.

[leozide]

I was afraid something like this would happen, I'll take a look at moving the hook to where you suggested.

[c-lipka]

You'll find that the image buffers currently used in that role use single precision float colour channels; this is necessary since the buffer is agnostic of the output image encoding details such as bit depth and gamma. 16-bit integers would only be good enough for 8-bit output file types, or 16-bit output file types using linear encoding, and half-precision floats would only be good enough for 8-bit and high dynamic range output file types.

You can reduce the memory size somewhat by dropping the "F" ("filter") channel, which isn't actually used. I haven't gotten around to throwing out that channel yet.

[chris20]

As clipka is no longer contributing to or part of the POV-Ray development team I have assigned this to myself. At the time, since he was taking care of pull requests I did not regularly check them myself. If I had seen his original comment about VFE not being part of POV-Ray I would certainly have corrected it.

VFE absolutely is part of the official portable POV-Ray code and is the recommended method for interfacing to the backend messaging system, POVMS. People are welcome to use raw POVMS if they wish, but that involves writing a lot more code.

Thus this change is eligible to be merged. However at this time I will leave it outstanding as I need to decide the best strategy of moving pull requests into the beta devel branch.