Paraview Parallel模式下的文件解析（四）

根据上一节的分析我们通过实验来看看vtkPVDataRepresentation这个文件中是否执行到了，然后再试试其几个子类：：

这个对象的

190::vtkPVDataRepresentation:;RequestData
189::vtkPVDataRepresentation::RequestData都执行了，说明确实是执行了这个对象，并且是在Update之后SynchronizeGeometryBounds之前进行，关键在第二次Update中却没有执行。这不合理啊。难道在这之中执行了？可是在这个函数中并没有找到相关的调用Representation的信息啊。

下面我们看它的子类vtkGeometryRepesentation：

189::vtkPVRenderView::Update
189::vtkGeometryRepesentation::RequestData
190::vtkPVRenderView::Update
190::vtkGeometryRepresentation::RequestData
190::vtkGeometryRepresentationMultiBlockMaker::RequestData
190::vtkPVDataRepresentation::RequestData
190::vtkGeometryRepresentation::RequestData
189::vtkGeometryRepresentationMultiBlockMaker
189::vtkPVDataRepresentation::RequestData
189::vtkGeometryRepesentation::RequestData
189::vtkGeometryRepresentationMultiBlockMaker
189::vtkPVDataRepresentation::RequestData
190::vtkGeometryRepresentationMultiBlockMaker::RequestData
189::vtkPVDataRepresentation::RequestData
189::vtkPVDataRepresentation::RequestData
190::vtkPVDataRepresentation::RequestData
190::vtkPVDataRepresentation::RequestData
190::vtkPVDataRepresentation::RequestData
189::vtkPVRenderView::SynchronizeGeometryBounds
190::vtkPVRenderView::SynchronizeGeometryBounds

很明显，这个类和其中的类vtkGeometryRepresentationMultiBlockMaker的RequestData都运行了。

我们首先来看看vtkGeometryRepesentation::RequestData：

首先把DataBounds置为未初始化状态。然后把caching imformation传递给catch keeper。

如果输入的vector的信息对象为一。执行 prod->SetWholeExtent(inInfo->Get( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT())，其中prod是这个输入的产生者。然后与Filter相连，执行 this->GeometryFilter->SetInputConnection( this->GetInternalOutputPort());

189::vtkGeometryRepresentation:;Request::numbenr1。我们可以看到，它执行进入了只有一个information对象的过程中。但是没有进WHOLE_EXTENT这个过程。然后通过输出端口获取数据。然后计算出这个数据的边界值。感觉这个方法就是算边界值，然后在后面的RenderWindow中使用啊。数据划分也不在这？接着执行父类的RequestData。发出命令UpadateDataEvent。这个机制一直想看看。

子类vtkGeometryRepesentationWithFaces意义不大，多了一个处理正反面的函数。

我们接下来看看vtkPVDataDeliveryManger这个类：

189::vtkPVRenderView::Update
189::vtkGeometryRepesentation::RequestData
189::vtkGeometryRepresentation:;Request::numbenr1

189::vtkGeometryRepresentationMultiBlockMaker

189::vtkPVDataRepresentation::RequestData
189::vtkPVDataDeliveryManager::MarkAsRedistributable
189::vtkGeometryRepesentation::RequestData

189::vtkPVRenderView::Update
189::vtkPVDataDeliveryManager::MarkAsRedistributable
189::vtkPVDataDeliveryManager::MarkAsRedistributable
189::vtkPVRenderView::SynchronizeGeometryBounds
190::vtkPVRenderView::SynchronizeGeometryBounds
189::vtkPVDataDeliveryManager::Deliver
vtkMPIMoveData::RequestData:::2
190::vtkMPIMoveData:mode1
190::vtkMPIMoveData:mode1::Pass_through
vtkMPIMoveData::RequestData:::2
190::vtkMPIMoveData:mode1
190::vtkMPIMoveData:mode1::Pass_through
189::vtkPVRenderView:;Render

我们可以看到，在我的常用过程中，是这样发生的。主要用到vtkPVDataDeliveryManager::MarkAsRedistributable和vtkPVDataDeliveryManager::Deliver，说明数据被标记为需要重新划分，并且进行了传输。在那之后就进行数据的转移，189上就是直接复制，190上要传递。这样看起视乎是没有错的。

想想我们整个系统应该是客户端控制的，所以一切命令的发起都是来自客户端的，在客户端中的vtkSMRenderView中我们看到了一些相关的操作。非常明显。在vtkSMViewProxy中，我们可以看到他的StillRender中有这么几个操作，先执行Update，这之中就是像服务器的vtkPVRenderView发送，执行SetUseCache，Update，执行PostUpdateData()这应该再往流水线的上端传递的意思，然后就还要更新数据的意思。