[PD] pd, openCV, pointers and indirection.

[Loic Kessous]

thanks Mathieu, it is still not clear for me what make things faster  
in one case or another but it helps.
loic
PS: what do you call Martin's strings ?

On 3 oct. 09, at 23:22, Mathieu Bouchard wrote:

> 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