[PD-dev] GEM development

[Daniel Heckenberg]

> From: g|nter geiger
> hi,
>
> sounds great,
> I have lately been trying to improve pix_ operations performance with MMX
> and switching to integer only calculations. ..
> One thing I ended up doing is to make the imageStruct a real class,
> which should make the handling of pixes a lot easier.

That's good news: those pix_es could definitely be optimized and MMX and
Altivec are great for image processing.  How far are you through this
process?

> > I've fixed the problems that I've encountered but they're quite
> drastic.  I
> > made the stoprender call part of the daglink structure rather
> than a method
> > of gembase.  This way it can be called on a per-input rather
> than per-object
> > basis.  This fixes all of the shutdown/object deletion crashes
> that I was
> > having with the released version of the code (0.87)
>
> I would  like to have a look at that. I don't really understand what a per
> input stoprender means.

There are problems in the release code when an dualpix object is deleted or
its stoprender method is called.  When stoprender is called (by traversing
down either gemlist) both of its cache pointers are NULLed.  This means that
when the object is deleted it can't call breakDAG for the other gemlist.  If
the objects are deleted in the "wrong" order when rendering is occuring (say
by closing the patch) then this can cause a crash.

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).

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.

> >
> > Has there been any discussion about the design of n-input GEM objects?
> >
> You mean n images input ? Not that I can remember.

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.

> I have already asked Johannes about setting up a CVS for GEM, this would
> make shared development a lot easier.

Yes, that would be good.  I note that there's already a CVS archive for the
GEM OSX project so it would be good to get a central repository up to keep
things consistent and organised.

> Can you send a diff against gem-0.87 of the changes you did ?

Sure, see attached.

I'll provide the following notes:
GemBase.h/cpp:		breakDAG/stoprender system changed to provide per-input
stoprender calls
GemPixDualObj.h/cpp:	breakDAG/stoprender system changed to provide per-input
stoprender calls.
				right render method now takes a copy of the current pix_block
pix_filmNT.h/cpp:		added error handling to film opening to handle
codec/decompression issues
				hacked in support to load 8-bit palettized AVIs and output them as
greyscale.

I've also written a fairly trivial pix_snap2tex object that snaps the frame
buffer to a texture (good for diffusion/feedback/motion blur effects).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DH_GEM.diff
Type: application/octet-stream
Size: 18761 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20020614/04347690/attachment.obj>