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