color in GLSL
Issue here is that intermediate result was clipped as an optimization in
such nodes and thus not converted to the correct type properly. Now only
clip those values if types match.
This keeps both the optimization and the conversion. I looked at
converting uniform types always but it's more involved to compare types
at conversion time for such links because the type was getting
overridden during link duplication.
It was possible that two threads will start calculating proxy group's inverted
matrix and store it in the object itself. This isn't good idea because it means
some threads might be using partially written matrix.
Previously it was very easy to run into situation when two objects are sharing
the same materials with drivers which will cause threading access issues.
This actually only needed for the old depsgraph, but since it's still the one
we're using by default we'd better solve this issue.
There were some reported data race conditions in the python interpreter which
seems to be rather valid.
Surely this is not very pretty solution, but it might solve some annoying bugs
related on threading.
For a long time this function was only intended to be used from the main thread,
but since out implementation of parallel range (which is currently only used by
mesh deform modifier) we might want to switch to threaded alloc from object
update thread.
Now we're using spinlock around the check, which makes the code safe to be used
from all over the place.
We might consider using a bit of atomics operations magic there, but it's not so
much important for now, this code is not used in the performance critical code
path.
Fix for T36639 caused all path changes to reload (which could loose user content).
Change behavior:
- Only reload data when a flag is explicitly passed
(currently only used by Find Files operator)
- Don't reload images which have been painted onto and not saved (dirty flag set).
The problem was that it was aborting too early after stumbling across a point which
might fit within the bounds required. This commit improves the logic here to solve
this and a few other little bugs like that.
Disclaimer: There are still a few cases where it randomly ends up picking something
way off. However, this only seems to occur very sporadically, so it's hard to say
how bad the problem may be.
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
