GitLab

The logic in vtkPVDataDeliveryManager that would result in deciding
which representation delivered data that the potential to miss
representation that produced empty data under special cases.
This was because vtkPVDataDeliveryManager was depending on data's MTime
which doesn't always change when `vtkPVDataRepresentation::RequestData`
is executed. Fixed that using a more robust
`vtkDemandDrivenPipeline::DataTime` instead.

Also added a test for the same.

Using `vtkMTimeStamp` instead of `unsigned long` for timestamps. This
was causing overflows on Windows causing vtkPVDataDeliveryManager logic
to get confused on long running animations for windows.

Using `vtkMTimeStamp` instead of `unsigned long` for timestamps. This
was causing overflows on Windows causing vtkPVDataDeliveryManager logic
to get confused on long running animations for windows.

vtkPVDataDeliveryManager only needs to use the information about known
representations, and not necessarily ports since that info is no longer
available until a representation executes, which need not be similar on
all clients e.g. is the master changes active representation type and
a slave joins after this change, it will now know of the old
representation (e.g. pvcs-collab.VariableSelection1 test).

Fixed that.

vtkPVDataDeliveryManager was always delivering data from all ports,
fixed that to only deliver data from ports needed.

Also the number of input ports to a representation has no bearing on how
many renderable artifacts it will produce. Removed that assumption.

This commit was generated automatically by running:

Utilities/Scripts/clang-format.bash --tracked

For unstructured grid volume rendering and semi-transparent
surface rendering provide an advanced option to skip geometry
redistribution for depth ordering. Also adding test for using data
partitions functionality.

vtkPVDataDeliveryManager was using incorrect geometry size for
vtkImageVolumeRepresentation. vtkImageVolumeRepresentation needed to
report the true data size to vtkPVDataDeliveryManager for it make the
correct decision. This commit fixes that by adding an API to
vtkPVDataDeliveryManager to pass in a "true-data-size" when passing
dataset to deliver.

Change-Id: Iff1bc45e18f35b1bf1c57739b23daa7441c5ecd8

vtkTextSourceRepresentation was unnecessary doing a data-clone (despite the fact
that all data-server nodes have valid data). This added unnecessary
communication between all processes and hence was causing a performance
degradation as experienced by BUG #14221 (and other Catalyst users). Fixed that.
vtkTextSourceRepresentation still needs data delivered to client always (since
the 2D renderer is not composited), but we ensure that we no longer to any
gathers/scatters thus avoiding parallel communication.

Change-Id: I98a85ef4b911f813533ab7ed7c0ee4cee2adbca1

Due to a bug in logic, despite best intentions
vtkStructuredGridVolumeRepresentation was ending up marking its data as
redistributable. Consequently, vtkPVDataDeliveryManager was redistributing it
which was negating the whole purpose of having
vtkStructuredGridVolumeRepresentation. This fixes that issues by adding API to
vtkPVRenderView to call MarkAsRedistributable() to unmark the representation as
redistributable.

Change-Id: I8474d2f9246b90b3989510688e2a6d67223f5fcb

This can happen when the RequestData of an algorithm fails.

Change-Id: I899ef01ca4b22d568ad1fb6254cf9be124b81160

When ordered compositing is enabled, ParaView determines the process order by
partitioning the data using PKdTree. However, in some cases, like when volume
rendering image-data, we need to override the partitioning using the partitions
from the image data itself. This commit cleans up the API for proving such
information to the view from a representation. In past it was tightly coupled
with vtkImageData producer. This change makes it possible to just pass the
meta-data about extent-translator to use, origin, spacing, extents etc. to
generate the partitioning. This will make it possible for non-image data
representations to provide this meta-data without having to create a
vtkImageData.

This removes obsolete vtkBSPCutsGenerator. Also vtkKdTreeManager now always
regenerates the KdTree. The checks to avoid regenerating unless the input
changed have been removed.

Change-Id: I469f54ba931fd64f66097d0ea579e9d8652d9bfc

Change-Id: Iacd01dec15644152eb9d0ff26963b34e798846b3

When playing animation, display lists are always discarded even if pipeline data
didn't change with time. Although the geometry filter and the vtkPVCacheKeeper
in vtkGeometryRepresentation didn't re-execute, the data was still treated as
modified. This was due to the logic in vtkPVDataDeliveryManager::SetPiece(). The
code was implemented to look at the DataTime provided by the pipeline. That was
done so that we could detect the change in data object when representation type
changes. However, the same can be done simply by comparing the data-object
pointer. Doing that addresses this bug as well.

Note however, in client-server mode, we still would force delivery for all
representations when time changes irrespective of whether the data really
changed.

Change-Id: I1b41778a5e3fcfa041ff48860c5311245a5182a7

Change-Id: Ieb91bb81ddf54d773a53fe68f5a77554f583c372

Change-Id: If6181d6753312ebc7148d163e91dd0d18c8f02b3

Cleaning up unused code in vtkPVDataDeliveryManager. That logic has now moved to
the representations themselves.

"AMR Blocks" streaming now works in client-server with local or remote
rendering. This updates the logic for delivering streamed pieces to rendering
nodes. Although both remote/local rendering are supported for streaming, if the
rendering mode is changed in between, the streaming is not restarted (currently)
and hence the blocks already delivered will not be available on the other
processes.

Tile display configuration also works.

This commit refactors AMR streaming framework and add support for a mechanism
for streaming composite datasets in general. To try out amr streaming, run all
executables with "--enable-streaming" flag and open an AMR Flash or Enzo dataset
and render as "AMR Blocks" or "Volume" (currently, only works in builtin mode,
but will be supported in other modes soon).

vtkAMROutlineRepresentation is a example class that demonstrates how a
representation can leverage the streaming capabailities provided by
vtkPVRenderView.

vtkPVRenderView adds support to two new passes: REQUEST_STREAMING_UPDATE() and
REQUEST_PROCESS_STREAMED_PIECE().  REQUEST_STREAMING_UPDATE() is a view pass in
which the representations can update their data pipelines to request a certain
"piece" of the data. REQUEST_PROCESS_STREAMED_PIECE() is called on
representations to handle a "piece" just received by the process. This
separation makes it possible for representations to be agnostic of where the
data is processed and where it is rendered. It's the reposibility of the view
(vtkPVDataDeliveryManager in particular) to deliver the data to the
rendering nodes.

vtkPVDataDeliveryManager doesn't currently support data delivery for streamed
pieces, however. That's on the TODO list.

Change-Id: I5eb7acea4fc149be4c87906cd77991ca17479120

vtkPVDataDeliveryManager's internal were changed as we were cleaning up the code
so that all ParaView use-cases work with the new delivery mechanism. Fixing
StreamingDeliver() to work after those changes. AMR streaming volume rendering
now works again when streaming is enabled.

vtkPVDataDeliveryManager needed to pass atleast data-type correctly on all
processes even if data was not being delivered on that process. This fixed that.

As user toggled the use outline for lod setting, the rendering mode won't
immediately update. This happened as the delivery mechanism didn't think it
needed to request new data. Ensure that it happens so.

If user swicthed from local to remote and back to local rendering without
changing the data, the rendering would be empty. This was happening since the
client accidentally removed the local data is had delivered previously. Fixed
that.

vtkPVDataDeliveryManager was ending up not requesting new data when slice
parameters were changed. This happened because the mtime we used in
vtkPVDataDeliveryManager used the data-time, which clearly didn't change on the
client after every update. Since vtkPVDataDeliveryManager::SetPiece() uses the
executive's data-time to check if data was really updated, we shouldn't use the
data mtime in vtkPVDataDeliveryManager's SetDataObject() call.

* Reintroduced support for generating kdtree using image data extents.
* Restructured code to ensure redistribution happens correctly for every render.
  The previous implementation required that the client triggered the
  redistribution in Delivery() call which was not possible esp. as
  representations were added/removed (since Delivery() is only called when data
  really needs to be delivered which is not the case when representations are
  removed).

* Surface selection now works in local-rendering mode (as well as remote
  rendering mode). It expects the vtkPVGeometryFilter to generate process ids
  (vtkProcessId) array in parallel. When present, it is used to determine the
  process id.
* Selection rendering passes now render the "original ids" rather than the
  point/cell ids. Thus representations no longer need to "convert" selection.
  They just need to ensure that they render the correct ids in the selection
  rendering passes.

This makes it possible to determine the "selection" directly on the client.
Thus, we no longer need to gather the selection from the server side.

Adding a new key, VIEW(), to the ProcessViewRequest() call to make it easier for
representations to access the view that is calling the passes.

Also fixed code to use correct block id when making requests.

vtkAMRVolumeRepresentation can now stream data. Client requests block at a time
and updates it. Still a work in progress.

We now expect representations to report bounds. This has to be done to avoid the
dependence on geometry to be available for rendering.