Change the OpenGL configuration to require GLEW as most of the OpenGL
code actually requires GLEW (or will as soon as the VBO branch gets
merged in).
Also removed some stray find_package commands and rearranged the
configuration to use the vtkm_configure_component_* commands instead.
452af3a0 Restore the AppendType and ReplaceType templates of FunctionInterface
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !570
ba8c8586 Get IntegerSequence to work correctly with MSVC.
377532c7 Update brigand to get a chunk of msvc2013 fixes.
a7f7cfe4 Update brigand.hpp to get corrections for MSVC2013.
a931b8e2 FunctionInterface and DispatcherBase don't require boost now.
ac0929a1 Add fast tracks for ListTag operations on size <= 4.
7ad88b6e Use c++11 variadic templates as storage of ListTags.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !559
One of the dashboard was complaining that the bottomLeft variable might
have been used uninitialized because it got set in a condition above it.
In fact, that condition is always true the first during the first
iteration, but it is not worth fighting the compiler over it. Instead,
just initialize the value of bottomLeft when it is constructed.
One of the dashboard compilers found a code path in PNGDecode where if
given a buffer too short for a header the info.width and info.height
were not initialized but their values still returned to the calling
function. This case does not really matter since an error is also
returned, but still technically incorrect. Fixed the problem by
initializing the width and height to 0 (which could help anyway if the
error is not properly checked).
This makes the name more consistent with the names of the other VTK-m
CMake options.
Also changed the default to be ON. I do not see a big downside to
compiling the rendering library most of the time.
123bc8b6 Add a configuration error if OSMesa was not found
0a61085d Do not load OpenGL libraries if OSMesa already loaded
640e92c7 Add VTKm_ENABLE_OSMESA option
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !548
If VTKm_ENABLE_OSMesa was on but OSMesa was not found, CMake would just
give a status update but happily configure. This change checks for the
condition where VTKm_ENABLE_OSMesa is on but OSMesa was not configured
correctly and raises an error in this case.
UnitTestMapperEGL.cxx: MapperGL is no longer a templated class.
UnitTestMapperGLFW.cxx: strmp needs cstring
rendering/CMakeLists.txt: need to append egl_sources to sources.
UnitTestMapperEGL.cxx: MapperGL is no longer a templated class.
UnitTestMapperGLFW.cxx: strmp needs cstring
rendering/CMakeLists.txt: need to append egl_sources to sources.
Add glut rendering unittest.
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
See merge request !546
The remove boost::shared_ptr and the rendering library branches where
developed simultaneously, and thus some of the rendering library
implementation was using boost::shared_ptr like the old code. Bring up
to date with the rest of VTK-m by using std::shared_ptr instead.
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
The clang compiler was running into linker errors constructors of
classes with virtual methods that were inline and destructors that were
not declared at all. In this case, the compiler was not creating
everything needed by a virtual table and the link died.
One of the dashboards is complaining about the destructor implementation
not being used in a particular test build. I suspect it is because the
export macro has an inline, so I am trying removing it.
I noticed that Visual Studio was taking an insane amount of time to
compile BitmapFontFactory.cxx (~20 minutes). Following some suggestions
on stackoverflow (http://stackoverflow.com/questions/7893850/long-
compile-times-in-visual-c-2010-with-large-static-arrays) I changed the
arrays to be static const (something that is more viable when compiling
a library instead of header-only). The compile after this changes seems
basically immediate now.
Also made the TextAnnotation classes conform better to VTK-m coding
style. Specifically, changed the order of words in subclass names (e.g.
TextAnnotationBillboard instead of BillboardTextAnnotation) and broke
out each subclass into its own header/source files.
When things in the rendering library need to execute things in parallel
(outside of another rendering library like OpenGL) it should run it on
available parallel devices. This means using TryExecute to attempt on
whatever devices may be available. It also means that some of the
sources must be compiled with CUDA's nvcc. To enable this, made a code
wrapping mechanism to compile within a .cu file.
This is using the C++11 override keyword to make the compiler check to
ensure that we are correctly overriding virtual methods when we mean to.
Currently this will not compile without C++11. However, we are planning
on moving to C++11 very soon, and we can fix the macro if we don't.
I have noticed at least on my windows machine that source code that uses
the rendering package is taking a long time to compile. The rendering
library does not rely much on templates and more on virtual methods.
Thus, it is a good candidate for moving to a library so that it need be
compiled only once.
This sets up the configure scripts to create the library. There is also
a simple port of one class to the library. More will follow.
Fix precision warnings when FloatDefault is 64 bit
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
See merge request !526
1881d375 Explicitly error out if vtk-m is used with a non c++11 compiler.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !532
call and then never upload again.
RenderTest: overload the Render function to pass in a Mapper.
UnitTestMapperGLFW: global variable for the MapperGL to pass into RenderTest::Render
MapperGL: Creating the VBO/VAO is now wrapped in check to see if the data's
already been loaded.
Moved some variables to class scope.
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
The UnitTestMapperGLFW test was coded to run in an interactive mode,
which was problematic when simply running the test. If no one was there
to exit the interactive window, the test would time out. This change
adds a "batch" mode that is on when run by ctest. The batch mode runs
through all configurations and exits.
Fix configuration of dependent rendering libraries
The VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
See merge request !519
The VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
Previously there was a bug where BufferTypePicker was not implemented
correctly when LONG was 32 bits (even though 64 bit integers were
available).
This changes fixes the problem and also makes the implementation more
general by using the TypeTraits already available.
The testing subdirectories were including the tests from the parent
directory. I believe this was a copy-paste error from the tests
originally all being in one file (where the unit_tests variable had all
tests appended) and then moved to subdirectories where they should not
be appended.
14ad996d Update vtk-m to use CopySubRange where applicable.
51e50d29 Add DeviceAdapter::CopySubRange to all device adapters.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !516
There were many tests that created code paths for every base and Vec
type that VTK-m supports (up to 4 components). Although this is
admirable, it is also excessive, and our compile times for the tests are
very long.
To shorten compile times, remove the TryAllTypes method. Replace it with
a version of TryTypes that uses a default list of "exemplar" set of
integers, floats, and Vecs.
