[Bf-committers] pixel get & image processing

Dan Eicher dan at trollwerks.org
Fri Jan 28 01:04:32 CET 2011


On Thu, Jan 27, 2011 at 4:02 PM, Campbell Barton <ideasman42 at 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


More information about the Bf-committers mailing list