This replaces usage of generic PLACEHOLDEWR with string lookup with more
explicit opcode. This should make it faster to build dependency graph by
avoiding string comparisons when it's not needed.
There should be no user measurable different.
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
Steps to reproduce were:
* Open Blender, create a new scene
* Go back to initial scene, transform object
* Switch back to newly created scene, change operator settings there
* Should cause a crash (at least with asan)
Should behave like 2.7 now, that is, switch scene back to where
operator was executed.
We wouldn't know which dependency graphs needs/safe for reconstruction,
so rather use API which tells that relations are out of date. This way
graph evaluation will take care of the rest.
Committing to 2.8 only since it's where we can't reliably know the graph
and is probably not that safe to apply this in master.
This needs to be re-implemented in a new fashion, without touching global list
of bases and become compatible with the new dependency graph.
The idea to go here would be to create new dependency graph for motion path
evaluation, bring a single object in there (which will pull all dependencies
at a construction) and use that.
Needs working copy-on-write first tho.
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
It will not be possible to do that after depsgraph becomes more context
oriented. Which means, all code will need to explicitly tell which graph
to free,
This is a first step towards an updated API where we pass explicit graph rather
than a scene. This is because we can no longer deduct which graph to use since
it will depend on a context.
Will happen in several steps, so bisecting will not be such a pain.
This is a corner-case, but one that is too easy to reproduce:
* Unlink all the collections of active view layer.
* Link a group without "Instancing" it.
The test will leak CPU devices, but is all passing other than that.
Leak will be fixed shortly.
P.S. Committing code refactor without running regression tests, tsk ;)
* Remove tex_* and pixels_* functions, replace by mem_*.
* Add MEM_TEXTURE and MEM_PIXELS as memory types recognized by devices.
* No longer create device_memory and call mem_* directly, always go
through device_only_memory, device_vector and device_pixels.
Was actually possible to invoke this assert failure in two ways:
* Transforming in newly created 3D View (like described in the report).
* Transforming in newly appended workspace from default workspaces.blend. Issue was that default workspaces.blend was saved in 2.8.1, but in a branch state that didn't include the transform-orientation changes. So versioning code wouldn't run when needed.
Note that files saved with this bug will still cause the assert to
fail. Can be ignored then.
This is not related to manipulators (as suggested in the report).
rna_scene.c was getting way too big with data that was related to
DNA_layer_types.h.
I tried doing it earlier, but failed. But now with the new changes I think it's
better to do this sooner than later.
