Make sure all header files are listed with build

This should help ensure that all files are properly installed.

See merge request !436

Not having them could cause compiler issues.

For header files, this only adds the file to IDE file lists, which is
convenient but not critical. However, the test did find a ligit error in
the hello_world example where the TBB build was actually using the
serial device adapter.

The benchmarking header files were not listed. Not a huge deal since
these files do not need to be installed, but they should be listed
anyway. Changed the vtkm_save_benchmarks CMake macro to be able to list
headers.

Also moved everything from BenchmarkDeviceAdapter.h to
BenchmarkDeviceAdapter.cxx. Since this code shouldn't need to be
included by anything except this benchmark, there is no need to have it
in a header file. Plus, the build changes would mean that any change in
the header (where most of the source was) could cause all code in this
directory to recompile. I do not want to set that precedent.

The test is a simple CMake script that finds all files in the build
directory with certain extensions (.h, .cxx, etc.) and makes sure that
the filename is listed somewhere in the CMakeLists.txt file of the same
directory. If the filename is listed in the CMakeLists.txt file, then
there is a good chance it is being addressed by the build.

This should help catch when header files are not being installed. It also
should help verify that test builds are being done on all files. It will
also highlight dead source files.

delete the vtkm::filter::FieldTypes header.



See merge request !434

Fix minor compile issues with font classes



See merge request !435

These compile warnings include implicit conversion from signed to
unsigned, a shadowed variable, and an unused static function.

Not all systems put their OpenGL headers in a directory named GL. (In
particular, OSX decides to be different.) The vtkm/rendering/internal/
OpenGLHeaders.h header takes care of including the OpenGL header on all
platforms.

This is required for installing the files. It is also useful for
developers because it adds the files to IDEs and creates test builds for
the header files. Those test builds highlighted some missing includes.

The header is used by nothing, and contains an old version of
the FieldMetadata class.

Adding text annotations to rendering

This adds bitmap font support and two types of text annotations - screen space text and world-space billboard text - as well as enables the labels in the axes.

See merge request !423

Reader should name fields only with their field name

The Legacy VTK file reader was augmenting all the field names with the
type of field. For example, if you had a point scalar field named
"elevation", it would be loaded as "SCALARS:elevation".

This is bad for two reasons. First, it is downright confusing. A tool
like ParaView or VisIt will tell me the field is named "elevation", but
VTK-m will report that field does not exist. Second, the writer does not
follow the same convention. Thus, if you have a loop of read file,
modify, write file, you could end up with fields named
"SCALARS:SCALARS:SCALARS:...".

See merge request !432

Fix endian flip when reading vector arrays

The legacy VTK file reader has a condition to flip the bytes in values
when the endian does not match the current system. The problem was that
when reading in a vector, the flip was happening on all bytes of a Vec.
This caused the last components of the Vec to be flipped with the first
components. Instead, we want each component to be flipped independently.

See merge request !433

The legacy VTK file reader has a condition to flip the bytes in values
when the endian does not match the current system. The problem was that
when reading in a vector, the flip was happening on all bytes of a Vec.
This caused the last components of the Vec to be flipped with the first
components. Instead, we want each component to be flipped independently.

Conflicts:
	vtkm/rendering/RenderSurfaceGL.h
	vtkm/rendering/Window.h

The Legacy VTK file reader was augmenting all the field names with the
type of field. For example, if you had a point scalar field named
"elevation", it would be loaded as "SCALARS:elevation".

This is bad for two reasons. First, it is downright confusing. A tool
like ParaView or VisIt will tell me the field is named "elevation", but
VTK-m will report that field does not exist. Second, the writer does not
follow the same convention. Thus, if you have a loop of read file,
modify, write file, you could end up with fields named
"SCALARS:SCALARS:SCALARS:...".

Robert Maynard authored May 31, 2016 and Kitware Robot committed May 31, 2016

317a48d4

 Prefer using PointCount instead of FromCount in cell based worklets.

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !431

Create Range and Bounds helper classes



See merge request !429

The PointCount name is far more descriptive and helps readers understand
what the content of the variable is.

In addition to this being necessary to be compatible with recent
changes, it makes for cleaner declaration of these values.

First, be more explicit when we mean a range of values in a field or a
spacial bounds. Use the Range and Bounds structs in Field and
CoordinateSystem to make all of this more clear (and reduce a bit of
code as well).

This is a simple struct that defines min and max values over X, Y, and Z
to define an axis-aligned bounding box.

This is a simple struct that has a min and max scalar value to represent
a range of scalar values. It also comes with several helper methods.

Add missing export macro to VecTraits

The VTKM_EXEC_CONT_EXPORT macro was missing from the
GetNumberOfComponents method in the VecTraits class for base C types.

See merge request !430

The VTKM_EXEC_CONT_EXPORT macro was missing from the
GetNumberOfComponents method in the VecTraits class for base C types.

Robert Maynard authored May 26, 2016 and Kitware Robot committed May 26, 2016

06a06b52

 Simplify the bounds computation code to reduce library size.

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !426

Robert Maynard authored May 26, 2016 and Kitware Robot committed May 26, 2016

5e200528

 Allow filters to have finer control on what cell sets they support

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !428

Robert Maynard authored May 26, 2016 and Kitware Robot committed May 26, 2016

6da2dc0c

 ArrayPortalFromIterators now can be explicitly instantiated.

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !427

The previous version of the bounds code required once less pass across
the data, but significantly increase the size of the resulting library:

Data for VTK-VTK-m interop:
  - 7k more symbol table entries
  - 1.5MB larger library

Because of the significant savings we need to use a less efficient
implementation that minimized the code size.

Certain algorithms like VertexClustering only work on certain cellset types.
It is pointless to generate the code paths for structured data cell sets,
when the algorithm can't operate on those dataset types.

Support OpenGL on Mac OSX

More fixes I needed to compile the OpenGL rendering examples on my OS X system.

See merge request !425

Template instantiation is useful because when you are creating object files, as
uninstantiated template definitions are not are not added. Fully supporting
explicit instantiation like ITK does will require more code changes, but
this is a very minor step towards that goal.

Specifically, I am trying to compile the code on OSX. OSX uses OpenGL
libraries in a different directory than most other installs (including
X11) and does not generally support GLX. These changes remove the files
that support GLX in systems that do not support it.

I also added several header files to the CMake lists that were not there
but should have been.

Fix warnings and style in rendering module

Fix some coding style issues and a few warnings in the rendering code.

See merge request !424