<div dir="ltr">Hi folks,<div><br></div><div>In an effort to address a bug reported on the mailing list, I ended up making a change to the way the pipeline is updated. I made a minor change to the way update behaves but more importantly, I'd like to make an API change that is biggish.</div><div><br></div><div>Here is how an algorithm is updated currently.</div><div><br></div><div>anAlgorithm->Update();</div><div><br></div><div>If you want the algorithm to produce a particular subset in space or time, you need to do this:</div><div><br></div><div>anAlgorithm->UpdateInformation();</div><div>anAlgorithm->SetUpdateExtent(0, 2, 0);</div><div>anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1);</div><div>anAlgorithm->SetUpdateTimeStep(0.5);</div><div>anAlgorithm->Update();</div><div><br></div><div>If you forget the UpdateInformation() part, this does not work. This is a problem because there are a bunch of disparate methods that need to be documented with information about the order of the method calls. Currently, this is tribal knowledge. The change I need to make to fix the bug reported makes things even more complicated. After the change, this will not work:</div><div><br></div><div><div>anAlgorithm->UpdateInformation();</div><div>anAlgorithm->SetUpdateExtent(0, 2, 0);</div></div><div>anAlgorithm->Modified();</div><div>anAlgorithm->Update();</div><div><br></div><div>The Modified() call causes the Information pass to execute again, which after my changes initializes the requests to default values (such as (0, 1, 0) for the piece stuff and WHOLE_EXTENT() for the extents). Without this change, there are subtle bugs that come up in filters and mappers. So now, we also need to document that you cannot modify the object  after UpdateInformation() (including calling any Set methods) for this to work.</div><div><br></div><div>Here is the change I'd like to make:</div><div><br></div><div>* Deprecate all of the SetUpdateXXX() methods.</div><div>* Add arguments to Update() that allows passing of requests</div><div><br></div><div>So the first example would look like:</div><div><br></div><div>int updateExtent[6] = {0, 10, 0, 10, 1, 1};</div><div>anAlgorithm->UpdateTimeStep(0.5, 0, 2, 0, updateExtent);</div><div><br></div><div>There are signatures for:</div><div><br></div><div>Update(int piece, int numPieces, int ghostLevel);</div><div>Update(int piece, int numPieces, int ghostLevel, int* updateExtent);</div><div>UpdateTimeStep(double time);</div><div>UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel);</div><div>UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel, int* updateExtent);</div><div><br></div><div>There is also a more flexible method with this signature:</div><div><br></div><div>Update(vtkInformation* requests);</div><div><br></div><div>This allows assigning any arbitrary number of requests for the update pass. For example:</div><div><br></div><div>vtkNew<vtkInformation> info;</div><div>info->Set(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP(), 0.5);</div><div>anAlgorithm->Update(info.GetPointer());</div><div><br></div><div>Finally, it is still possible to do the "updateInfo -> set request -> update" thing like this:</div><div><br></div><div><div>int updateExtent[6] = {0, 10, 0, 10, 1, 1};</div></div><div>anAlgorithm->UpdateInformation();<br></div><div><div><div>vtkInformation* outInfo = anAlgorithm->GetOutputInformation(0);</div><div>outInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),</div><div>  updateExtent);</div><div>// Don't modify the object after this</div><div>anAlgorithm->Update();<br></div></div><div><br></div></div><div>This is the advanced use case.</div><div><br></div><div>Here is the branch that passes all of the tests:</div><div><br></div><div><a href="https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change">https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change</a><br></div><div><br></div><div>It is WIP because I need to add some better documentation.</div><div><br></div><div>What do you think?</div><div>-berk</div></div>