[PD] sending image from of / libpd

[Peter Brinkmann]

On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard <matju at artengine.ca>wrote:

> On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
>
>  why not simply resize the internal array as needed, starting with 32
>> elements and doubling whenever the limit is reached?
>>
>
> binbuf could be used for that, if the libc's realloc does in effect the
> same thing. i think that this is the case with modern glibc (Linux/CygWin)
> as well as Perl's allocator (when I looked at it 10 years ago), but not
> necessarily other libc implementations (FreeBSD/OSX, Google, Microsoft) that
> I didn't try it with, so if anyone could check, that would be interesting.
>
> To test that, add millions of atoms to a binbuf and see how much time it
> takes. A «bad» implementation will roughly quadruple the time each time you
> double the number individual additions, whereas a «good» one will just
> double the time.
>

For the time being, I have something much simpler in mind: Just take the
current call "int libpd_start_message(void)", which returns the current
limit, and replace it with "int libpd_start_message(int length)", which
takes a parameter indicating the length of the message and returns a nonzero
error code if the length is too big.

I like this idea because it's almost as simple as the original approach, and
the API agnostic with respect to the policy for handling long messages.  The
tentative implementation that I have right now still has the hard-coded
limit of 32 elements, and libpd_start_message simply returns an error code
when asked for a message with more than 32 elements.  The next revision will
dynamically resize the array if the requested length exceeds the current
size, and it will only return an error code if the allocation of a larger
array fails.  Either way, there's no need to reallocate because the array
contains nothing of interest when libpd_start_message is called, and so we
can simply throw away the old array and allocate a new one.

The only disadvantage I see is that this doesn't sit well with the
streaming-style C++ wrapper that Dan created for ofxPd, but I can think of
workarounds for that.
Cheers,
     Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110830/ac00fefd/attachment.htm>