[PD-dev] GEM development

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

On Fri, 14 Jun 2002, Daniel Heckenberg wrote:
> To solve this I added a stoprender function to the render and postrender
> functions that are kept in the DAG list.  Now a per-input stoprender
> function can simply clear that input's cache and if/when the object is
> deleted the unbroken DAGs can be properly broken.  There may well be a
> better/more elegant way to do this, but this seems to fit with the present
> code.
>
> The other obvious alternative is to pass the message down the PD connections
> (as happens when the DAG is constructed).

I am not yet really into the source, but a feeling tells me that the
message passing solution might be more the way it should be.
The "render chain" or dag (what does this stand for ?) commands should
probably  really only do the rendering... have to look at it further,
maybe Mark or Johannes can tell you more about this.

>
> There's another problem in the GemPixDualObj class, in its RightRender
> method.  GemPixDualObj copies the GemState->image pointer to use later when
> its left render occurs.
>
> This fails in the following case:
> If there are pix_fx objects in this right gemlist, they will reset the
> GemState->image pointer back to their "oldImage" values when their
> postrender functions are called.  That means that when the GemPixDualObj
> Render occurs, its m_pixRight member will not be pointing to the correct
> image.  This can cause strange problems like the [pix_data] problem that I
> reported, as well as more catastrophic problems if the image format is
> converted upstream (ie if there is a [pix_rgba] in the fx chain that is
> effectively rolled back before the GemPixDualObj occurs.)
>
> As the pointer copy occurs regardless of the newImage flag, another problem
> arises:
> If pix_fx objects are in a chain and going into the right input of a
> GemPixDualObj and the render chain is running without the newImag flag set,
> the fx won't run but the image will be taken anyway.

Hmm, problem I may be solved by doing the postrender call after all
gemheads have been rendered, and not on a per render chain.
This would break rendering with a "bang" on the gemhead though.

Probably it would make sense to hook all objets into one gemhead, but then
ordering would not work anymore, so we need a "gemtrigger"...
... finally I think I might talk complete nonsense ...

> Looking through the per-input code above, the obvious question is "how to
> make this easily extend to n-input objects?". The motivation for n-input
> objects seems pretty clear: e.g doing n layer compositing would be much
> neater and faster that way.

ah, forget about the point I was making in my last mail about that,
there are probably hundreds of thinkable effects that just might use
three image or more as an input.

making image processing work in a similar way that signal processing
is done in pd would be really cool. Having a basic set of objects to
build homegrown video effects ...

Guenter