Was there any resolution or successful workarounds for this issue? I'm
running into these identical symptoms with an Iop that creates and
manages multiple Read Ops. Any suggestions would be appreciated.
-sean
On 03/26/11 08:37, Moritz Moeller wrote:
On 03/26/2011 04:24 PM, Moritz Moeller wrote:
I seems calling asap_update() before request() solves it.
[...]
I have to run more tests to confirm but so far it looks like it is a
workaround to the "black rows on first request()" issue.
Correction. I also have a check for is_zero() in my loop!
If I remove this check, I get black pixels again.
It really looks like the is_zero() request is pulling the data. Again,
this doesn't help if asap_update() wasn't called before. Code looks like
this:
_node->asapUpdate();
_node->request( Mask_RGBA, 1 );
ChannelSet channelMask( Mask_RGBA );
channelMask&= _node->info().channels();
unsigned short channels( channelMask.size() );
Row row( 0, width );
bool allZero( true );
for ( unsigned short scanLine( 0 );
scanLine< height;
++scanLine )
{
_node->get( scanLine, 0, width, channelMask, row );
foreach( channel, channelMask ) {
if( !row.is_zero( channel ) ) {
allZero = false;
}
// use row[ channel ] somehow
}
}
This works but is a big wtf for me now. Any insights as to what I may be
missing are still welcome. :)
Again, for the 2nd request, it always works, even if I do not call
asap_update() or is_zero().
.mm
_______________________________________________
Nuke-dev mailing list
[email protected]
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
