search

POV-Ray / povray

The Persistence of Vision Raytracer (POV-Ray)
https://www.povray.org/
GNU Affero General Public License v3.0
1.37k stars 282 forks source link

Added shared memory option for the render buffer #344

Open leozide opened 6 years ago

leozide commented 6 years ago

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 commented 6 years ago

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.

leozide commented 6 years ago

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

c-lipka commented 6 years ago

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.