Actually, this one is more complicated, because it involves the underlying pix buffer. That has nothing to do with OpenGL...
Mark > -----Original Message----- > From: Chris McCormick [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 07, 2006 7:49 PM > To: chris clepper > Cc: Danks, Mark; Mathieu Bouchard; pd-liste; vincent Rioux; IOhannes m > zmoelnig > Subject: Re: [PD] pix_record mixed pixes > > On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote: > > On 12/7/06, Danks, Mark <[EMAIL PROTECTED]> wrote: > > > Reversing the order pix_invert and pix_record will still apply the > > >invert?it will just happen after the pix_record happens. > > > > That is a much clearer way to say what I was try to say. The inversion > will > > not be applied to the image input to pix_record, but the processing > would > > still happen. > > Well, I don't want to speak for Matju, but I think what he's saying is > that he realises this, but it is counter intuitive and suprising. If I > have a dsp or message graph and I send the output of something through > some modifiers, I don't expect those modifiers to be automatically applied > to another cable going somewhere else. I expect modifiers further down > the tree to only effect things on the same branch. Essentially, when > patching Gem, you have to be even more aware of the order of operations > than when just regularly patching dsp, because operations on one branch > of the graph can affect operations on another branch of the graph. I > guess one way to 'fix' that (and break backwards compatability) would > be perform a GLPushMatrix every time there is a fork in the graph, > and a GLPopMatrix every time you get to a leaf node. > > Best, > > Chris. > > ------------------- > [EMAIL PROTECTED] > http://mccormick.cx _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
