Rework the CompositePolyDataMapper2
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.
Showing with 2522 additions and 1644 deletions