[vtk-developers] Performance issue regarding vtkOpenGLGlyph3DMapper with large number of vtkDatasets

Haocheng Liu haocheng.liu at kitware.com
Mon Apr 9 11:52:35 EDT 2018


Hi David and Ken,

David is right about the number of mappers and actors.

On Mon, Apr 9, 2018 at 11:36 AM, David Thompson <david.thompson at kitware.com>
wrote:

> Hi Haocheng,
>
> > I have a use case that I want to glyph several hundreds of vtkDatasets.
> However, the frame rate becomes super slow since vtkOpenGLyph3DMapper would
> call rebuildstructures function for each dataset. With 258 vtkDatasets, it
> takes more than 4 seconds to render one frame and spends 52% of the time
> doing rebuilding stuff(Rebuilding the structure 258 times even though
> nothing new!). I'm thinking to remove Line 515 in /Rendering/OpenGL2/vtkOpenGLGlyph3DMapper.cxx
> and pass a flag instead to trigger the rebuilding if a new color is
> assigned.
>
> I'm not sure that change would not be enough to guarantee that the
> vtkOpenGLGlyph3DMapper::vtkOpenGLGlyph3DMapperEntry objects are kept up
> to date.
>
> It might be better to understand why the mapper's MTime is being updated
> every render. If we can't use the mapper's MTime, then we should probably
> add a new MTime member to the mapper that gets modified when things that
> *do* matter (like block color changes) occur.
>
> Mapper's MTime is updated because a mouse movement would trigger
*vtkCompositePolyDtaMapper2::ComputeBounds*. It would then update vtkMapper
MTime. I'm looking at the proposed method now.

>         David




-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20180409/3962bc49/attachment-0001.html>


More information about the vtk-developers mailing list