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.
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
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
