-
Notifications
You must be signed in to change notification settings - Fork 214
DiskBlur #6529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DiskBlur #6529
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Daniel! Seems to be working nicely in my limited testing, and at a pleasing speed.
I've taken a top-down approach to review, mostly commenting on the user-visible stuff and the overall code structure. I see you have a bunch of TODO items for documenting specific functions/sections, but I think what would be more valuable would be some higher-level introductory description about the overall strategy.
Like I say though, seems to be working well, so I don't think we should spend too much time reorganising. If my suggestions about object-orienting things like the scanline LUT don't chime with you, then let's just add some high-level commenting and move on.
Cheers...
John
I've run into a crash in
|
Addressed in 7b997ae |
Finished the documentation / cleanup pass on the low level details. |
b3cb0fa
to
489e5df
Compare
Thanks for the update Daniel - I've gone through it all and closed the relevant conversations, and added comments to a few others. |
489e5df
to
6d96519
Compare
Addressed all remaining comments, plus two commits optimizing computeScanlinesLUT: 4bb69b0, 1600519, and a final commit adding a Changelog entry. To the best of my knowledge, this should be good to merge, aside from not having been squashed yet - it will be a trivial squash, everything just goes into one commit. |
Thanks Daniel - I've replied to a couple of things inline, but I think we're close enough to merge if needs be. Seems worth getting into today's alpha release either way... |
src/GafferImage/DiskBlur.cpp
Outdated
// It shouldn't be necessary to hash the maxRadiusPlug here, since we include it's actual value in | ||
// the hash below ... but for some reason, removing this line shows a 10% degradation in one | ||
// performance. Hashing the maxRadius in twice isn't hurting anything. | ||
maxRadiusPlug()->hash( h ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's vexing - any theory as to why? hashChannelData()
isn't even called that often, so I'm struggling to see why this would be so at all.
src/GafferImage/DiskBlur.cpp
Outdated
void DiskBlur::hashDeep( const GafferImage::ImagePlug *parent, const Gaffer::Context *context, IECore::MurmurHash &h ) const | ||
{ | ||
ImageProcessor::hashDeep( parent, context, h ); | ||
h.append( false ); | ||
} | ||
|
||
bool DiskBlur::computeDeep( const Gaffer::Context *context, const ImagePlug *parent ) const | ||
{ | ||
return false; | ||
} | ||
|
||
void DiskBlur::hashSampleOffsets( const GafferImage::ImagePlug *parent, const Gaffer::Context *context, IECore::MurmurHash &h ) const | ||
{ | ||
h = ImagePlug::flatTileSampleOffsets()->Object::hash(); | ||
} | ||
|
||
IECore::ConstIntVectorDataPtr DiskBlur::computeSampleOffsets( const Imath::V2i &tileOrigin, const Gaffer::Context *context, const ImagePlug *parent ) const | ||
{ | ||
return ImagePlug::flatTileSampleOffsets(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it makes sense to just have these be pass-through connections from the input
I perhaps wasn't clear enough, but by "these" I was referring to hash/computeSampleOffsets()
too.
7012521
to
ea91464
Compare
Addressed final round of minor feedback, and squashed so it's ready to merge. |
ea91464
to
c39d4e6
Compare
It's been a bit of a scramble to turn this from research code to something properly tested and reasonably cleanly layed out.
I'm now feeling fairly good about the reliability and overall organization of this code. There are definitely still some of the lower level parts that could use more comments ( like applyScanlinesHalfKernel and the compute() for scanlinesLUTPlug() ), but I know I've already spent too long cleaning this up. Hopefully the overall state is somewhere where it can be reviewed somewhat productively.