[PD] pd, openCV, pointers and indirection.

[Mathieu Bouchard]

On Sat, 3 Oct 2009, Loic Kessous wrote:

> I understand your point of view, but I am more interested buy the 
> approach than the implementation itself. I mean passing a pointer and 
> not the image itself.

"Passing the image itself" is largely a myth anyway.

At a first level, Pd doesn't always pass $1, $2, $3, etc., as separate 
arguments in C: it often passes the pointer to the list (under the name 
"argv"). This is what always happens for running list-methods and 
anything-methods, as well as when sending list-messages and 
anything-messages (pd automatically converts argv to non-argv and non-argv 
to argv whenever needed).

At a second level, not much large data is passed as pd arglists: some 
notable exceptions can happen in [pix_data], [pix_set], [#to_list], 
[#import], [pix_convolve]'s config, Martin's strings, etc.; plugins such 
as Gem and GridFlow use a second level of pointers to avoid Pd's argv. 
This is mostly for this reason: because Pd's argv is limited to being a 
t_atom array, which is usually too big and inefficient for 
tightly-formatted data, spending 8 or 16 bytes on storing a 4-byte float 
when you just want to store a single-byte int, for example.

But then, with either level, the way of specifying the pointer to the list 
allows basically anything to happen, as the pointer doesn't have to be 
stack allocated. With argv, methods aren't allowed to rely on a past 
argv after the return is done, but still, the sender of the message can 
decide the argv to be anything, not necessarily on the stack; this can 
happen to be fairly permanent data.

Beyond that, there is a distinction between systems that let the user deal 
with the "pointerness" aspect, and those that try to hide it (to make it 
more automatic and easier to think about, they pretend to "pass the image" 
but doesn't really). Outside of Pd, both strategies are widely used. Perl 
and Tcl are very good examples of strings that never look like they use 
pointers but always do. In Pd, ... only GridFlow uses something that looks 
like "pass the image" semantics but has a few gotchas, and it's also the 
only one that can pass an image without allocating a buffer of the same 
size as the image. In the end, all the video frameworks make the user mess 
with pointers in some way:

   * Gem's [pix_separator]
   * PDP's [pdp_trigger]
   * GridFlow's [#t]
   * MaPoD even required the user to free() image buffers using a special
     object-class.
   * FrameStein: i don't know (sorry).

> That's why it's compiled as a dll library I suppose

I don't see any link between any of the above notions, and the kind of 
linkage (dll, etc) it uses.

> and I wonder how using another solution as shared memory for example 
> could be done in the same goal... loic

No idea what you are referring to. I know what shared memory is, I know 
what indirection is, but I don't know what is the problem that the 
solution solves, you didn't say that. (And if anything, shared memory 
introduces new portability concerns.)

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801