(obj);
}
else
{
return vtk*Filter::New();
}
}
```
That way, the problem would be solved for other VTK applications, not just ParaView.
I guess the right way might be to create an abstract superclass shared among the “serial” and “VTK-m” versions. I’m not sure how necessary that is.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 8, 2021, 11:37pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/4 "2021-06-08T23:37:29Z")
Do the VTK-m filters have the same results as the VTK filter it represents? What if a user wants `vtkmContour`, but `vtkOtherVtkmFilter` in the same pipeline (say, due to memory limitations on their GPU if both are active at the same time)?
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [June 9, 2021, 2:27pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/5 "2021-06-09T14:27:07Z")
In principal, yes, the VTK-m filter should have the same results as the VTK filter. It should be transparent to the user. Of course, the two outputs might not be bitwise-equal. A contour could, for example, easily have the polygons in a different order or different decisions for ambiguous cases. But such changes can happen from one version of ParaView to the next, so I don’t think that would be an issue.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 9, 2021, 8:02pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/6 "2021-06-09T20:02:55Z")
OK, just making sure 🙂 .
---
### Author:  [@vbolea](https://discourse.paraview.org/u/vbolea)
#### Post date: [June 15, 2021, 3:11pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/7 "2021-06-15T15:11:51Z")
> Should this factory implementation be handled in the VTK layer instead? Perhaps the `New` method of the vtk filter could instantiate itself with the object factory.
I really entertained this idea and I spent a good time figuring out how to approach this, I came up with the following scheme onto how to implement it:
- Note that thanks to the `vtkFactories` `vtk*FilterExtended` does not depend onto `vtkm*Filter` at the implementation level,.
- Also, instead of a Abstract class I added a subclass where this switch is done. This is mainly to avoid modifying the VTK filters hierarchy. It is basically a Decorator with `vtkFactories`
While this will indeed benefit other VTK applications, this approach requires to:
- On ParaView, vtkPV_Filters to subclass on this new vtk_FiltersExtended (Not a big deal)
- While the `vtkFilterExtended` does not include the `vtkmFilter`. At the module level, we do have to include as dependency the VTKm module in order for this whole factory thing to work (AFAIK).
I am hesitant to add those changes for VTK mainly since it will add a hard dependency onto VTKm.
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [June 15, 2021, 4:14pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/8 "2021-06-15T16:14:38Z")
I was actually thinking something more like this:
([pdf version](https://discourse.paraview.org/uploads/short-url/1kZ7FsScgT6lUT1ws1bSymscF41.pdf))
You could rename the current filter (let’s call it `vtkFooFilter` so we don’t have wildcards) to, say, `vtkFooFilterSerial` (or something else appropriate). Then, create a new class with the original name (i.e. `vtkFooFilter`). This class has the same interface as the original filter, but it is an abstract class.
Per the rules of abstract classes in VTK, you should be able to call the `New` method, and the `New` method will use the `vtkObjectFactory` to create a concrete class. By default, the `vtkFooFilterSerial` will be registered with the `vtkObjectFactory`. However, if VTK-m is compiled, `vtkmFooFilter` can be registered instead.
Note that this means that any existing code that currently uses `vtkFooFilter` will continue to work as before. If VTK-m is not installed, when they call `vtkFooFilter::New()`, it will get `vtkFooFilterSerial`, which is the exact same implementation as before. However, if VTK-m is compiled, the code will get and use `vtkmFooFilter`.
Also note that this is exactly how the object factory is supposed to work.
The PV version of the filter (assuming we need a special PV version of the filter at all) simply needs to get a `vtkFooFilter` as before.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 15, 2021, 4:29pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/9 "2021-06-15T16:29:19Z")
Note that the library needs linked to (and passed to `vtk_module_autoinit`) to work for compiled code (in general). Python will need to import the appropriate VTKm module in order to guarantee the factory implementation is registered. Note that _where_ it is imported/instantiated doesn’t really matter, but it does need to happen.
---
### Author:  [@vbolea](https://discourse.paraview.org/u/vbolea)
#### Post date: [June 15, 2021, 4:32pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/10 "2021-06-15T16:32:19Z")
This looks like a very sound design, however, my main concern is that in this design, In the module corresponding to `vtkFooFilter` (vtk.module) , don’t we have to add vtkm as a dependency? Because the New() method will be defined there? I am not 100% sure though.
Note that, I already understood this idea in the first comment and I shared it, but I tweaked it to accommodate this concern in the previous comment
---
### Author:  [@berkgeveci](https://discourse.paraview.org/u/berkgeveci)
#### Post date: [June 15, 2021, 4:32pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/11 "2021-06-15T16:32:39Z")
This is actually somewhat similar to how it is currently implemented. The VTKm filters all inherit from the serial implementation so that they can call the superclass if the VTKm version fails for some reason. Using the factory method in the superclass and registering the VTKm subclasses, you would get the same end result. Ken’s design is cleaner on one hand but does not allow for delegating to superclass like the current implementation.
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [June 15, 2021, 4:36pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/12 "2021-06-15T16:36:40Z")
Yes, the delegation is an issue I didn’t address. I figured the VTK-m subclass would have a “has-a” link to the VTK subclass for the fallback. I didn’t put that in the diagram to hopefully make it less confusing.
---
### Author:  [@vbolea](https://discourse.paraview.org/u/vbolea)
#### Post date: [June 22, 2021, 10:48pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/13 "2021-06-22T22:48:45Z")
One thing we might have missed in the discussion is whether it is a good idea to implement our own New method. Revering engineering the macros, in its implementation, it appears that it does what we are discussing here (if certain cmake options are set), but I can see that if in the future there are changes to those macros, we might be missing out those changes in the filters here discussed.
We could introduce another factory method, however, it will add reduce consistency in the code-base in the sense that the standard new method will not be enough to create certain filters.
Without the new method and without introducing a new factory method we do not really have a way on doing this switch in the VTK layer.
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [June 23, 2021, 12:15pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/14 "2021-06-23T12:15:35Z")
Here’s another slightly different approach. This allows for specialization based on input data types / element types etc. It does mean the `vtkFooFilter` will need to be involved in making the decision on which `vtkBaseFooImpl` subclass to create but that’s probably better since it allows for more informed decision making.
In this design, vtkFooFilter becomes the `vtkAlgorithm` subclass that implements the vtkAlgorithm API along with defining the public API for the filter. However, it uses a `vtkBaseFooImpl` abstract class to do the actual execution. This keeps us from having several different subclasses or variants of `vtkFooFilter` based on input type or other specific criteria. For example, we could have one `vtkSurfaceFilter` and different internal implementations based on input type, cell type etc. rather than having multiple versions. Same for `Isocontour`, for example, or `Threshold` – the list goes on. Thus, rather than having the users choose which filter to use for their type of data and environment, the decision is passed on to the VTK developer.
`vtkFooFilter` can expose API to choose a specific implementation, if necessary.
What this also allows us is to build composite filters with ease. For example, An IsoVolume filter wants to do a Threshold internally when computing isovolume for cell data. It can directly use the `vtkIsoVolumeImpl`. This avoids executing all the `vtkAlgorithm` passes on this internal filter – which can easily add up.
* * *
Furthermore, `vtkBaseFooImpl` should probably not use the simple `New`, instead support the following (or similar).
```auto
vtkBaseFooImpl* New(vtkInformation* params);
```
The `params` can be used to pass key-value pairs that help choose the implementation to use. Now the logic to choose best implementation can be in `vtkBaseFooImpl` itself. Now, ObjectFactory API should also be extended similarly to allow for customizing and extending this logic. The keys available can be defined in `vtkBaseFooImpl` itself, e.g. for the diagram shown, we can have the following:
```auto
class vtkBaseFooImpl : public vtkObject
{
public:
// Choose a specific runtime.
static vtkInformationStringKey* RUNTIME();
// Indicates if data type.
static vtkInformationIntegerKey* DATA_OBJECT_TYPE();
// Some impls may want even more control, say they want to look at what
// type cells are present, or for composite dataset, what types of individual datasets
// are present. For those, we can even pass the input data object instead of just the type.
static vtkInformationDataObjectKey* INPUT_DATA();
...
};
```
The `vtkFooFilter` will use these keys to populate a `vtkInformation` object in `RequestData` to create the right `vtkBaseFooImpl` subclass and then use it.
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [June 23, 2021, 2:25pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/15 "2021-06-23T14:25:33Z")
Addressing @vbolea, custom `New` methods are possible, but I’m not sure why we would want them. The macros for abstract and concrete classes seem to do what we want. I don’t expect the object factory classes/macros to change. They were old when I started using VTK over 20 years ago. And if someone does change them, it is on that person to fix any classes that rely on its behavior.
As for @utkarsh.ayachit’s design, that sounds like positive value. But I note that this is really expanding the scope of the work. This design is no longer about “hiding VTK-m filters” but redesigning complex filters that have multiple implementations. Also, it’s a design that will have to be reimplemented for every filter, and it might be overkill for simple filters.
---
### Author:  [@vbolea](https://discourse.paraview.org/u/vbolea)
#### Post date: [June 23, 2021, 3:42pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/16 "2021-06-23T15:42:03Z")
> Addressing @vbolea, custom `New` methods are possible, but I’m not sure why we would want them. The macros for abstract and concrete classes seem to do what we wan
Yeah I was referring and evaluating the proposed idea of moving custom New methods to the vtkFooFilters in the example that you wrote earlier in this thread.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 23, 2021, 4:56pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/17 "2021-06-23T16:56:41Z")
@utkarsh.ayachit’s `vtkInformation` passing echos of [this issue](https://gitlab.kitware.com/vtk/vtk/-/issues/17218) to allow for more control over object factory selections (right now, you just hope that the one you want is first in the list). In light of [enable/disable APIs](https://gitlab.kitware.com/vtk/vtk/-/issues/18170) for factories, any such mechanism should also have a way to influence within a scope.
However, given VTK’s propensity for global state (which is a problem in the context of threading) and no parameters to constructors (with configuration after-the-fact), any viable solution is going to end up being ugly I imagine.
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [June 23, 2021, 5:04pm UTC](https://discourse.paraview.org/t/hiding-vtk-m-filters-in-paraview/7379/18 "2021-06-23T17:04:02Z")
> [@Kenneth\_Moreland](#):
>
> But I note that this is really expanding the scope of the work.
Fair point. I’ll defer to you and others working on this to determine that. It may be worth exploring this option when the opportunity presents itself, though. Maybe we decide to take a serious look at DataSetSurface filter (and GeometryFilter and the ilk), we can explore this approach.