Connect an input to OFX-plugin and then read an image via Tile from it in _open. I have not tested this on Nuke 6.3, but on 6.2 it causes a Nuke to hang. I think it because OFX plugins do not support request, and there occurs cross blocking, when it is initializes while some other _open executing.
2012/6/14 Steven Booth <[email protected]>: > Georgly, > > Why is that? Please explain. > > Steve > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Georgiy Osipov > Sent: Thursday, June 14, 2012 2:09 AM > To: Nuke plug-in development discussion > Subject: Re: [Nuke-dev] need advice about single-thread engine() call > > Be careful, do not read input imaged in _open() method. It can create serious > problems for example with OFX plugins. > > 2012/6/7 Steven Booth <[email protected]>: >> Ah! Got it. I tend to do such things in the _open method, actually, >> and then use the threaded, parallel engine calls to actually render >> the data computed in open. >> >> >> >> Steve >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Kin >> Ming Mike WONG >> Sent: Wednesday, June 06, 2012 10:25 PM >> To: Nuke plug-in development discussion >> Subject: Re: [Nuke-dev] need advice about single-thread engine() call >> >> >> >> hi steve, >> >> >> >> about "typical", i was referring to using the { Guard guard(_lock); } >> approach to achieve a single threaded engine() call, sorry for the >> confusion. >> >> >> >> it's because I need to do a parallel reduction on the image data using >> existing tbb processing function, so it's important to get the >> tile/image processed as quickly as possible by upstream nodes from my >> single-threaded >> engine() call and then forward the data to my processor. any >> suggestion on this ? >> >> thanks, >> >> mike >> >> >> >> On Wed, Jun 6, 2012 at 10:56 PM, Steven Booth <[email protected]> wrote: >> >> Mike, >> >> >> >> Each node is implemented as a separate class, and each has a unique >> instantiation of the associated engine method. It is therefore not >> the case that a single, one-threadded node will cause all nodes above >> it to operate in single-threaded mode. That presumes there is one and >> only one node connected to each output, which may not be the case. It >> is, however, true that your single-threadded node will create a >> bottleneck, slowing down whatever path your node is in. >> >> >> >> Although it is true that you can request Tiles in multi-threadded >> mode, if you're only going to process it in a single thread, it won't >> speed things up. >> >> >> >> It's a bit strange, though, that you call a single-threadded engine >> 'typical', because the normal methodology is multi-threaded. >> >> >> >> Might I ask why you need to process things single-threadded in your node? >> >> >> >> Steve >> >> >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of >> mike.artixels >> Sent: Wednesday, June 06, 2012 4:38 AM >> To: [email protected] >> Subject: [Nuke-dev] need advice about single-thread engine() call >> >> >> >> Hello everyone, >> >> I have a small plug-in which relies on typical single thread engine() >> call using Guard to do some pre-processing of the upstream image data, >> and if I understand correctly, this single threaded call will simply >> turn every upstream nodes running single-threadedly too .... so everything >> slows down. >> >> Is there any trick that I could pull data from upstream multi-threaded >> ? or am I missing or misunderstood anything here .... >> >> many thanks !! >> >> Mike >> >> (CONFIDENTIALITY NOTICE: The information contained in this email may >> be confidential and/or privileged. This email is intended to be >> reviewed by only the individual or organization named above. If you >> are not the intended recipient, or an authorized representative of the >> intended recipient, you are hereby notified that any review, >> dissemination or copying of this email, or the information contained >> herein is strictly prohibited. If you have received this communication >> in error, please notify the sender by return email and delete this >> email from your system. Thank You.) >> >> >> >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> >> >> (CONFIDENTIALITY NOTICE: The information contained in this email may >> be confidential and/or privileged. This email is intended to be >> reviewed by only the individual or organization named above. If you >> are not the intended recipient, or an authorized representative of the >> intended recipient, you are hereby notified that any review, >> dissemination or copying of this email, or the information contained >> herein is strictly prohibited. If you have received this communication >> in error, please notify the sender by return email and delete this >> email from your system. Thank You.) >> >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > (CONFIDENTIALITY NOTICE: The information contained in this email may be > confidential and/or privileged. This email is intended to be reviewed by only > the individual or organization named above. If you are not the intended > recipient, or an authorized representative of the intended recipient, you are > hereby notified that any review, dissemination or copying of this email, or > the information contained herein is strictly prohibited. If you have received > this communication in error, please notify the sender by return email and > delete this email from your system. Thank You.) > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
