4650a1da9 Deprecate old methods from DynamicCellSet
0b84787f7 Deprecate DynamicCellSet and remove from code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2661
The `DynamicCellSet` (and the related `DynamicCellSetBase`) are
deprecated and replaced with `UnknownCellSet` (and `UncertainCellSet`).
Thus, `UnknownCellSet` has some methods inherited from `DynamicCellSet`
but replaced with other functionality. These methods are now marked as
deprecated and their use is removed.
The `DynamicCellSet` class is now marked as deprecated (as is the header
that contains it), and all non-deprecated code is moved to its
`UnknownCellSet` replacement.
Also added a deprecation warning for the VariantArrayHandle.h header
file and deleted a couple inappropriate uses of it.
0a89a5fff Store UnknownCellSet instead of DynamicCellSet in DataSet
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2654
`UnknownCellSet` is an updated replacement for `DynamicCellSet`. The
next step in the replacement is to change `DataSet` to use the new
class.
Also replaced `DynamicCellSet` with `UnknownCellSet` in a few
places where `DynamicCellSet.h` was not directly included (and
therefore now no longer included at all). This change would have
to be made at some point anyway.
To avoid having to use a device compiler every time you wish to use
`ArrayGetValue`, the actual implementation is compiled into the `vtkm_cont`
library. To allow this to work for all the templated versions of
`ArrayHandle`, the implementation uses the extract component features of
`UnknownArrayHandle`. This works for most common arrays, but not all
arrays.
For arrays that cannot be directly represented by an `ArrayHandleStride`,
the fallback is bad. The entire array has to be pulled to the host and then
copied serially to a basic array.
For `ArrayGetValue`, this is just silly. So, for arrays that cannot be
simply represented by `ArrayHandleStride`, make a fallback that just uses
`ReadPortal` to get the data. Often this is not the most efficient method,
but it is better than the current alternative.
We have been doing a better job at hiding device code (and moving code
into libraries). Smoke out source that no longer needs to be compiled by
device compilers.
It looks like there might be a precision problem that is causing some
rays to terminate before they start. However, I leave that to someone
else to diagnose.
I suspect that this test is not actually mapping colors correctly, and
the difference in images might be part of that problem. However, I leave
that to someone else to diagnose.
The `test_equal_images` function has been expanded to supply the
generated image in a `Canvas` or a `DataSet` in addition to a `View`.
Much of the templating code has been removed from `test_equal_images`
and most of the code has moved into the `vtkm_rendering_testing`
library.
The previous functions that enabled the render regression tests were
heavily templated, which required every test using rendering to
recompile the entire rendering system being used. Changed the interface
to not rely on templating so that the RenderTest method can be moved
into a library.
Also moved the options into a struct where they can be better managed.
The render testing functions tended to have lots of arguments that were
difficult to manage. Instead, created a single `struct` that holds all
the potential options. That way when someone specifies on option, it is
clear what option is being set.
The tests that used rendering and image comparison were named
`RegressionTest*`. However, this name is not very descriptive as all the
tests are regression tests. These have all been renamed to be
`RenderTest*` to more clearly indicate that they are tests that use
rendering as part of the test.
Previously, all methods in the `vtkm::cont::testing::Testing` class were
inlined in the header file. This makes sense for the methods that are
templated, but not so much for methods that are not templated.
Although this change provides minimal improvements with compile times
and object sizes (maybe). But the real benefit is that some of these
methods declare static objects. When declared in inlined functions, a
different object will be created for each translation unit. This can
lead to unexpected behavior when multiple versions of a supposed
singleton static object exist.
