Second method for not having python crash blender on invalid access (ifdef'd out ATM, so no functional change).
This uses a weakref list per ID, and invalidates all members of that list when the ID is freed.
the list is not stores in the ID pointer but using a hash table since storing python in DNA data is not acceptable.
This is more correct then the previous method but shows down execution of scripts significantly since its always adding and removing from lists when data is created and freed.
This uses pythons GC so its no overhead during runtime but makes removing ID's slower.
Commented definition 'USE_PYRNA_INVALIDATE_GC' for now, so no functional change.
the length check was running sequence checks on every number which would fail, small speedup by avoiding this.
should eventually get this working faster by reading once into an allocated array.
Annoyance was that operators that defined and __init__ function would need to do...
def __init__(self, another_self):
....
py/rna was calling the class directly with PyObject_Call() but needed to pass the pre-allocated object only so __init__() would run .
This works OK internally but becomes messy since __new__ and __init__ always get the same args there was no way to avoid a superfluous self argument to __init__.
r34883).
Full description:
When defining an operator button in the UI layout code, trying to set
the value for such an operator's enum properties, where said enum uses
a dynamically generated list of items (which depends on using context
info), will "fail". No context info will be passed to the callbacks
used to generate this list of items, as PROP_ENUM_NO_CONTEXT is still
set on the operator properties (it seems these will only get cleared
when the operator actually runs, which is far too late already for
this usage) so RNA_property_enum_items() will pass NULL instead of a
context pointer *even* when one exists!
I'm not sure of why we even need this flag. It seems to have caused a
few other rounds of problems already, from quick searches I did on
this matter...
- rename rna collection structs Main prefix to BlendData: eg, MainObjects --> BlendDataObjects
- printing python collection now prints its type (when available)
- renamed shadowed vars in bpy_rna.c.
- when making functions static I also made debugging/test functions static, reverse and add definitions to headers instead.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
- KeyingSetInfo classes are now collected like Panels, Operators etc so bpy.utils.register_module() can be used.
- move bpy.types.register() to bpy.utils.register_class
- operators which reload G.main would crash blender if called from python and then accessed bpy.data.*
- WM_read_homefile_exec was setting the contexts Scene to NULL as a signal for the event system, this didnt work in background mode, crashing when property update functions expected scene to be set.
- now writing to RNA is disabled when inside render() call.
- disallow calling operators when writes are disabled.
Rendering runs in a thread so running operators from the thread is not safe unless rendering becomes a blocking operator again.
disable getattr metaclass forwarding attributes from the python class, eg:
bpy.types.Scene.foo != bpy.types.Scene.bl_rna.properties['foo']
... This was convenient but too tricky to properly maintain with attribute assignment and attributes defined within the class.
avoid doubles in dir() by converting to a set and then back to a list.
- values were added to both the classes __dict__ as well as the internal StructRNA.
- made properties available from the type since this is where the python api assigns them:
>>> bpy.types.Scene.frame_start
<bpy_struct, IntProperty("frame_start")>
- rename RNA_struct_type_properties() -> RNA_struct_type_properties(), added RNA_struct_type_find_property()
- avoid looping over the entire collection unless a negative index is used.
- dont use the get index function for building the slice list, instead loop over the collection until the stop value.
Speedup for getting collection indices, avoid getting the collection length unless a negative index is given. This avoids a loop over the entire collection in many cases.
Speedup for getting collection slices by detecting collection[:] and internally calling collection.values(), this gives a big speedup with some collections because each slice item would loop over the list until that index was found.
Rough test with 336 objects.
- getting index of listbase collection ~ 5.0x faster
- getting index of array collection ~ 1.15x faster
- getting slices of listbase collections ~ 34.0x faster
- getting slices of array collections ~ 1.5x faster
