There is currently no straightforward way to move a vtkDataObject from the client to the server.
This is something we will definitely need and we have a few use cases.
Open a small local file when working remotely
Generate data with numpy in python shell and visualize it
Store data in Qt resource file before being transferred to the server (eg default textures)
vtkNetworkImageSource and vtkMPIMoveData are already present but they do not allow for this operation yet.
Do you have any input on how we should process in order to cover these use cases ? The more generic the better.
All these simply sound like actions application needs to do in response to specific user interaction. I’d recommend putting this in a utility class or a helper proxy. You can mechanisms similar to those used by vtkSMProxy::ExecuteStream to push local “data” to remove using client-server stream.
I’ve put together a vtkSMProxy::CallMethodWithDataObject and it works well.
However, I’m not sure how to manage that correctly statefile-wise.
My use case is as follows : I have a default texture on the client that is sent through this new method to the server. The texture proxy end up saved on the state file and just can’t be reloaded as the data is, of course ,not stored in the statefile.
Since these default textures are always available, i suppose I should just not save them at all in the statefile, do you have a suggestion ?
Sure. This usecase can be generalized though, but here is this specific one.
I wan to have default loaded texture in ParaView. You open ParaView, and a few Textures are already present in the texture combobox.
In order to do that, I need to store the png somewhere and I decided to store them in the QRessources.
The QRessource are available only on the ParaView Qt Client side though, so I need to read the QImage, transform it into a vtkImageData; create the texture proxy and transfer the image to the server and the texture (this was the reason for my initial post).
I’m doing that on server creation and this is working great, however, since the image is not stored in the proxy properties, but only transfered through a specific method, it is not possible te recreate this state using state files.
And for sure, If I save a state, the texture proxy is here. If I load this state, the texture proxy is created but no vtkImageData are available in the vtkTexture, hence crashing the feature and ParaView.
The solution imo should be to not save these proxy in the state file at all.
I would have thought of this differently. I’d simply go by having a location on disk under share/ relative to the executables where default available texture files can be found. Now you can use the existing infrastructure to load the textures. First time the texture menu is clicked on, you can trigger some code to look for and populate the menu with available textures.
The QResource approach has another issue that it does not work in pvpython, so I don’t think that’s a good approach, in any case.
By that do you mean on loading state the background texture user had chosen will simply not be loaded? In that case, that’s not an acceptable solution. The feature is not usable if it cannot be restored from state file since saving and restoring state files is a very common use-case that people rely on.
I would have thought of this differently. I’d simply go by having a location on disk under share/ relative to the executables where default available texture files can be found. Now you can use the existing infrastructure to load the textures. First time the texture menu is clicked on, you can trigger some code to look for and populate the menu with available textures.
That would be a way to implement it, but I would rather find a solution not writing on disk
The QResource approach has another issue that it does not work in pvpython, so I don’t think that’s a good approach, in any case.
I’m not sure we need to support default texture in python. If not in a QRessource, where can I store a png ? directly encoded in the code ?
The solution imo should be to not save these proxy in the state file at all.
By that do you mean on loading state the background texture user had chosen will simply not be loaded? In that case, that’s not an acceptable solution. The feature is not usable if it cannot be restored from state file since saving and restoring state files is a very common use-case that people rely on.
Not at all. The default texture are always available, wheter you load a state file or not. They do not need to be recreated.
What I mean is that we should not save TrivialProducer proxies in the state file as they just can’t be reacreated from it. This issue is present with Catalyst live visualization as well.
Why? I don’t see the advantage of not having the textures on disk. Note, background textures may be decent sized esp if they are to render smoothly on large screen. In fact, it’s conceivable that users will use multiple resolution textures and expect PV to choose the best resolution for user’s current screen. In that case, compiling them into the executable is not a very attractive solution.
That would be a way to implement it, but I would rather find a solution not writing on disk
Why? I don’t see the advantage of not having the textures on disk.
We either write in the userspace ~/.config/ParaView/DefaultTextures or we deal with permission issues.
Then all statefile contains reference to these files which are not actually data in the mind of the user.
Note, background textures may be decent sized esp if they are to render smoothly on large screen. In fact, it’s conceivable that users will use multiple resolution textures and expect PV to choose the best resolution for user’s current screen. In that case, compiling them into the executable is not a very attractive solution.
I’m talking about very small texture here, not user defined textures.
I am talking about distributing with the ParaView executable itself, similar to how the documentation PDFs or material files are distributed. They are not in user space. The texture proxy should indeed be setup so that the default textures are identified by name and not filename.
I don’t think it’s a worthwhile feature if it’s not capable of supporting large background textures. See videos generated by most organizations like NVidia when they have background image with their branding. It’s always highres.
I am talking about distributing with the ParaView executable itself, similar to how the documentation PDFs or material files are distributed. They are not in user space. The texture proxy should indeed be setup so that the default textures are identified by name and not filename.
I get it now, managed by the superbuild ! I very much like this solution.
However, this is a specific usecase solution.
How should we manage the case where one move data from the client to the server and then save a statefile ? This is currently done in Catalyst with a GetClientSideObject, and will be supported with a remote using the new method I’m implementing, see first post.
The most simple way would be to set a flag on the proxy so it is not saved at all. Another way would be to support that only on TrivialProducer and actually save the data on disk when saving the state file. Any ideas ?
I’d need a good use-case for this. In general, this is an odd requirement for ParaView so I don’t think we should support it unless a convincing use-case exists.
As far as the catalyst issue is concerned, I’ll need to look into in separately since I am not sure what’s the deal there. State files and catalyst-live is indeed an unsupported case right now. State files are per session. When connected to catalyst live session, you have 2 session: the builtin one and the catalyst one. That’s not something that we explicitly handle – another reason why Catalyst live is indeed ALPHA for me. It should be a separate discussion, however.
not a case that we support, I am afraid. It needs more proper and targeting thinking. Off the top of my head, if you generate data using numpy on the client, how do you expect to split it on parallel ranks? why not use python programmable filter? it’s probably better esp if you’re fetching data from server, then doing work locally and then pushing the data back. All I am saying is this is not a natural ParaView use-case and if we want to add support for it, we need a more focused discussion than a segway on this discussion topic. For your specific texture use-case, I’d recommend sticking with the solution similar to material files that I suggested and you seem to agree.
