On Thu, Jan 27, 2011 at 4:02 PM, Campbell Barton <ideasma...@gmail.com> wrote: You could question why not just add this in our C api, a memoryview > patch has been submitted for this. > It would work but it doesn't solve the problem of restricting access > and I'm making an effort not to allow too much custom-py-c-api code > into blender, since it has a tendancy to feature-creep. > 2.4x py api was over 100,000 lines. Initial 2.5x RNA api over ~1500 > lines (not including rna_*.c), now its approx 6000 since it includes > code for keyframing, array/mathutils access and registration but I > really want to keep it small.
It's not the size of your api that matters, it's how you use it... The simplest solution would be do a BKE_image_acquire_ibuf() in getbufferproc and then a BKE_image_release_ibuf() in releasebufferproc. Easy peasy, the imbuf stays locked as long as python has a live memoryview object on it. Maybe change things a bit so another process could get a read only buffer ptr so the ui could be updated as python did it's stuff. Also, it shouldn't be too hard to make an rna hook for tp_as_buffer so this could be per-object instead of in the pyrna_struct base class where is obviously doesn't belong. rna_struct_tp_as_buffer_procs() or something along those lines. But the main problem imo is that py_buffer support only half works -- only supports bytes and a single dimension arrays contrary to what the docs say -- so you have to do all sorts of .to_char() shenanigans to do anything useful with it which would really suck if it were extended to support the rect_float buffer...and apparently the dev who implemented it up and disappeared so there's no timeline for it working to the PEP specs. Dan _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
