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

根据前文提到的/Parallel中的文件的实验发现，数据的传输是发生在vtkMapper之后，也就是vtkMapper请求数据之后，也就是Rendering这个过程之中，所以今天解析一下

/VTK/Rendering/Parallel/下的文件：

vtkClientServerCompositePass::这个类是一个render-pass，能够控制服务器和客户端的图像输送。这个类被设计用来在两进程配置的配置文件之中。这个类应该不是我们需要的。

vtkClientserverSynchronizedRenderers::这个类是vtkSynchronizedRenderers的子类，被设计用于两进程，客户端-服务器模式。

vtkCompositedSynchronizedRenderers::这个类是一个vtkSynchronizedRenderers的子类，使用vtkComposite去头结点上组合图像

vtkCompositer::在多进程中操作，每一个compositer有一个render window。它使用vtkMultiProcessControllers去与process 0 的render window通讯 color和depth buffer。他对透明度的控制不是很好。

vtkCompositeRenderManager::用来控制sort-last并行渲染的对象。它是vtkParallelRenderManager的子类，使用组合实现并行渲染。这个类已经代替了vtkCompositeManager.这个类也需要注意。

vtkComopositeRGBAPass::合成不同进程的RGBA  buffers。通过头结点进程的RGBA buffer去合成卫星进程的RGB buffer。卫星进程的RGBA buffers是不会变得。这个pass需要OpenGL上下文支持纹理对象和像素buffer对象。如果不支持，那么会报错，并且渲染他的代理并且返回。

vtkCompositeZPass::合并多个进程的深度buffers。把卫星进程的深度buffers合成到头进程的深度buffer中。子进程的深度buffer不变，这个传递需要OpenGL上下文支持纹理对象和像素buffer对象。如果不支持，那么会报错，并且渲染他的代理并且返回。
vtkCompressCompositer::实现合成的压缩树。这个类在多个进程上操作。每一个compositer有一个render window。它使用vtkMultiProcessControllers去与process 0 的render window通讯 color和depth buffer。他对透明度的控制不是很好。

vtkImageRenderManager::一个用来控制sort-first并行渲染的对象。它是vtkParallelRenderManager的一个子类。使用RGBA混合实现并行渲染。这是vtkCompositeRenderManager的一个反面。他依赖渲染流水线和vtkCompositeRGBAPass去初始化。组合的意义只在于layer 0 上的renders。这个类感觉有可能是我们需要注意的。

vtkParallelRenderManager::控制并行渲染。它提供合适的renderers和render windows以实现并行渲染。他也能把自身绑定到render windows上，并且传播渲染事件和camera views。需要注意的是，需要的并行渲染规划都不能准确的控制透明度。

vtkPHardwareSelector::用于并行渲染，他依赖于这个事实，这个应用将要使用一些其他的机制以保证renders在所有进程上的windows上保持同步。同步有头结点发起，当头结点渲染时，所有的进程也跟着渲染。只有在头结点上的vtkPHardwareSelector实例触发这些renders。所有其他的进程，只要监听StartEvent开始渲染，并且在渲染的开始要保证vtkPHardwareSelector的CurrentPass已经更新到了最新。

vtkSynchronizedRenderers::通过进程同步renderers。它被设计用于结合vtkSynchronizedRenderWindows去确保render windows在这些进程间的同步。这个类控制render中参数的同步，例如viewport,camera 参数。它不支持组合渲染图像，必须写一个子类实现组合算法。或者用一个库，例如IceT。

vtkSynchronizedRenderWindows::同步render windows。

vtkTreeCompositer::基于组合实现树。多进程中操作，每一个composite有一个render window。它使用vtkMultiProcessControllers去与process 0 的render window通讯 color和depth buffer。他对透明度的控制不是很好。

/VTK/Rendering/ParallelLIC/下的文件：

vtkMPIPixelTT::特征类，用于转变vtk 数据类型到需要的C或者MPI的数据类型。

vtkMPIPixelView::模板方法。帮助创建在vtkPixelExtent中详细描述的MPI数据类型

vtkParallelTimer::对于并行算法的时间分布式日志。当文件在每个进程中写由rank 0（按排序顺序把文件写到一个单一文件上）收集的数据时，在功能上提供分布式日志。这个log通过事件堆实现。EventStart把事件identifier和开始时间push进栈。EventEnd提取出最近的来并且计算差的秒数并且增加一个入口到这个log事件记录，他的开始和结束时间，相差秒数，它是单例的。

vtkPLineIntergralConvolution2D::基于GPU部分并行的线积分卷积的实现。实现算法的并行部分。

vtkPPainterCommunicator::一个只包含执行painter链的序列的Communicator。在一个painter中能够安全的使用一个Communicator。一个简单的container操控一个MPICommunicator。这样简单的API对于一系列引导执行程序的代码是很有效的。

vtkPPixelTransfer::移动通过范围描述的像素数据。操控进程间对非连续的共享索引的空间区域上的像素数据的通讯。例如复制复制一幅图像的子集到另一幅图像上，通过设置source和destination为相同范围的di，从而这个类能被用于纯粹的本地的非连续数据的转移。

vtkPSurfaceLICComposite::在并行的LIC中移动数据。这个类分解了图像空间，并且通过重要的网格避免在分解界限上的问题从而混乱了这个图像空间数据到新的分解上。当这个图像的LIC在新的分解上计算完成之后，这个类将会不混乱的把这个LIC放回原来的分解上。

vtkPSurfaceLICPainter::vtkSurfaceLICPainter的并行部分。

经过在vtkParallelRenderManager的：

vtkParallelRenderManager::SatelliteStartRender()；

vtkParallelRenderManager::StartRender()

这两个函数中加上输出，发现这两个函数在我们的基本过程中都没有使用到。难道在基本过程中并没有用到sort-first？那么数据是在哪分发的呢。如果数据分发了，而又没有使用sort-first，那么必然分发的数据就不是可以用vtkMapper直接读的数据咯，那是不是IO之后就直接分发给子节点服务器了，然后再子节点服务器上再进行数据处理？可是这样又会感觉不是很合理是不是，既然数据都读到内存中了，为何不处理呢，难道处理的时间要很久？是对polydata处理吗，还是怎么样？Mapper需要的数据又到底是什么呢，不是polydata这一层次的吗？