[Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Ken and Utkarsh, Checking back in with this issue... I still find that
interaction with the g-2 ring in ParaView v5rc2 is very slow compared to
v4.4. It looks like you all have a solution in mind. I'm happy to build
from master to try it if the solution is there. Thanks again and Happy
Holidays!!!  I really appreciate you all looking at this problem. -- Adam

*------*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
lyon at fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <ken.martin at kitware.com> wrote:

> You could maybe have an actor per LOD and then swap actors in and out.
>
> Actor owns the property, backface property, and texture. Changes to those
> objects can cause VBO/IBO rebuilds (switching from surface to wireframe,
> adding a texture map, flat versus phong shading, edge visibility, line
> width, etc.) The old backend only looked at the actor's property which is
> sort of broken.
>
> For example in the old backend: create two properties, one set to
> wireframe, one set to surface. Then create an actor and mapper set to use
> display lists. Switching between the two properties will cause an actor
> mtime change, but the properties themselves would still have low mtimes I
> believe. In that case the old backend will end up stuck in one
> representation because it only looks at the property mtime not actor.
>
> To make the VBO/IBO rebuild safely (but less often than currently) I think
> the solution is to check the mtimes as is done currently, if those are
> modified then collect up the parameters that require a VBO or IBO rebuild
> and compare them to a stored value from the last build. If different force
> a rebuild. That is the best solution IMO just takes some time. I sort of
> wanted to do that anyhow but now I can say you forced me into it :-)
>
> Thanks
> Ken
>
>
>
>
> On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit <
> utkarsh.ayachit at kitware.com> wrote:
>
>> > I did notice PV is forcing the actor to be modified every time the LOD
>> > changes (which is a lot). Modifying the actor causes the VBO/IBOs to
>> rebuild
>> > so it would be better not to do that unless you really need to and in
>> this
>> > case I'm not sure why it is being done. Specifically I think it is in
>> > vtkPVLODActor::Modified where it calls this->Device->Modified() . The
>> LOD
>> > actor is being modified as a result of calling SetEnableLOD constantly
>> > flipping between true and false. That is not the cause of this issue
>> but it
>> > is something I noticed that will be a pain for large datasets.
>>
>> Ken, currently, there's no way around it. vtkPVLODActor works by
>> changing the mapper on the internal vtkActor aka Device when LOD mode
>> is toggled. That will indeed change the Device's MTime even if we stop
>> calling this->Device->Modiied() in the vtkPVLODActor::Modified(). The
>> question is why are VBO/IBOs rebuild if actor MTime changes? VBOs
>> would be data dependent right? Most of data-dependent properties are
>> on  the Mapper, not the actor. Shouldn't the code that re-creates
>> VBO/IBOs only depend on Mapper's MTime?
>>
>> Utkarsh
>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151216/e173da67/attachment.html>