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