It is stored in the representation associated with the source. The representation controls how the source is displayed in ParaView, and it includes a Visibility property.
You can use display.Visibility to check whether the representation associated with source is visibile.
I believe that there is a bug in the initialization of existing objects when creating a new renderView.
Manually switching the visibility of all objects from hidden to visible and back to hidden again after creating a new renderView is a workaround.
Okay, this is a little subtle, and has to do with representations being lazily created.
After you load your state file, the representation in RenderView1 is created, exists, and is not visible. There is no representation created for the FastUniformGrid1 object in RenderView2. When your script processes RenderView2, it invokes GetDisplayProperties() which will create a representation for FastUniformGrid1 (since it does not exist for RenderView2) and shows the representation. Hence, the visibility is on in RenderView2, even though it is off in the first renderview.
The behavior arises because the mechanism for creating a representation is to call Show() (realy ts equivalent deeper in the ParaView libraries). We could potentially separate the representation creation from showing it and call the creation function if needed in GetDisplayProperties(). There may be some technical difficulties doing that that I am not aware of, but it’s a possibility.
The behavior is still present and it’s really annoying when working with multiple render views.
Currently, for every filter you add in one render view, you’ll have to go through all the other render views and manually make the filter visible and then invisible again.
Otherwise, loading the session in pvbatch, these filters will be visible in the other render views.
Man, this one was interesting. Definately down the rabbit hole for me.
I had to hack the python slightly. I am sure my crude sollution is due to my not understanding dictionaries. I had to change the GetSources line to be:
** sources = GetSources()
** source = FindSource(‘FastUniformGrid1’)
My users don’t use different layouts (I believe), mainly because I don’t teach them about layouts.
My users generally don’t use scripting that isn’t created with the trace recorder.
My users have never complained about this issue.
My $0.02 is that this is a very rare bug with a workaround. Should be fixed, but probably low on the queue. @cory.quammen, you agree? I know how to replicate it now, want me to write it up?
@bastian This is one of the best bug reports I have seen. Thanks for the time writing it, and well done.