Patrick Hodoul pointed out that we were forcing OpenColorIO to
initialize and read configs as soon as the ShadingSystem was
created. In this patch, we're changing to a lazy creation approach.
We remove the `OCIOColorSystem m_ocio_system` member and the
ocio_transform() method from ShadingSystem. Put them in the
ShadingContext instead. This allows lock-free access because each
context is used by only one thread at a time.
Within the OCIOColorSystem, make the `OIIO::ColorConfig` be a
shared_ptr rather than a member, so it can be created lazily. If the
Context's OCIOColorSystem needs a config and doesn't have its own yet,
it asks the ShadingSystem, which allocates one the first time (and
only that one time).
So, in short, SS allocates *one* shared ColorConfig, the first time
any context asks for one. The Context only asks the SS for this once
per context (i.e., once per thread). Individual shades just use the
ColorConfig of their context, not needing to lock for it (except for
that brief lock the first time any context asks for the very first
ColorConfig that's needed).
Some things were guarded by `OIIO_HAS_COLORPROCESSOR`, which is silly
because we no longer support OIIO versions so old that it's not
defined. But then OSL `undef`ed it for Cuda. I replaced these guards
by a more straightforward direct test of whether it was Cuda code.
I added a sample OCIO config to testsuite so we can use it for tests.
In particular, the new testsuite/ocio -- test using OCIO for color
transforms.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Larry Gritz
bee949cd3b