1. 20 Sep, 2016 9 commits
  2. 19 Sep, 2016 13 commits
  3. 18 Sep, 2016 3 commits
    • Ken Martin's avatar
      Merge topic 'new_composite_poly_mapper' · 789bce2c
      Ken Martin authored
      7912d340 Rework the CompositePolyDataMapper2
      Acked-by: Kitware Robot's avatarKitware Robot <kwrobot@kitware.com>
      Merge-request: !1909
      789bce2c
    • David Gobbi's avatar
      Merge topic 'double-underscore' · b73d4acc
      David Gobbi authored
      ad5c04cc Remove double underscore from include guards
      Acked-by: Kitware Robot's avatarKitware Robot <kwrobot@kitware.com>
      Merge-request: !1972
      b73d4acc
    • Ken Martin's avatar
      Rework the CompositePolyDataMapper2 · 7912d340
      Ken Martin authored
      The old approach used a fast path for a very narrow set of
      conditions and then used a slow path for everything else.
      This approach required two sets of code,
      
      - GenericCompositePolydataMapper2
      - CompositePolyDataMapper2
      
      and had performance issues as the slow path was slower
      than OpenGL1 for some cases. This reworking consolidates
      the two approach together. The basic approach is that
      all blocks with the same VBO structure get grouped together
      and rendered as one. The number of different VBO structures is
      small so this results in a a small number of things to render.
      
      Each of those things (handled with a Helper class) gets rendered
      using its own VBO and IBOs with special code to handle the cases
      where uniforms have to be changed between blocks etc.
      
      The results are generally much faster. Some additional
      optimizations have resulted in further performance improvements.
      Generally this new class is as fast as the old fast path and
      tens to hundreds of times faster for the slow path.
      
      This class is still complex and could probably be reworked
      another three times. The complexity is largly driven by
      how complex the task is as each block can have different
      primitives, point/cell data arrays, etc.
      
      This topic adds four more tests for this class. As this
      class is the workhourse for ParaView it really needs far
      more testing in VTK. The three additional tests cover
      some use cases I know tend to cause issues.
      
      At the same time this topic changes how point picking is
      done to prevent some bad behavior. The old approach
      rendered surfaces for all passes up to the primId pass.
      The problem with that is that the point pass rendering may
      not match up with the surface rendering resulting in point
      Ids associated with incoreect composite/prop/process ids.
      It mixes two sets of data haphazzardly. Very bad. This
      topic cuases all point selection to be done by rendering
      points.
      7912d340
  4. 17 Sep, 2016 2 commits
  5. 16 Sep, 2016 13 commits