Updated the image reader classes to better follow VTK-m naming
convention (i.e. use `ImageReaderPNG` instead of `PNGReader`).
The structure of the image reader class now also better matches
the interface for the VTK reader.
Also put the implementation of the image readers into the `vtkm_io`
library so that it only has to be compiled once.
The new and improved vtkm::cont::ColorTable provides a more feature complete
color table implementation that is modeled after
vtkDiscretizableColorTransferFunction. This class therefore supports different
color spaces ( rgb, lab, hsv, diverging ) and supports execution across all
device adapters.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
This commit converts `Canvas` from an abstract class to a concrete
class by converting the pure virtual methods to empty/default
implementations. It provides an implementation for `Canvas::AddLine`
using Bresenham's line drawing algorithm.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
Instead of labeling each method that needs to have visibility
we can label entire classes, this reduces the amount of noise and
potential for mistakes when writing classes.
Before this commit, there were three separate classes (Mapper, Canvas,
and View) that were all managing their own version of the background
color. As you can imagine, this could easily become out of sync, and in
fact if the user code did not specify the same background at least
twice, it would not work.
Fix this by consolidating the background color management to the Canvas.
This is the class most responsible for maintaining the background. All
other classes get or set the background from the Canvas.
That said, I also removed setting the background color from the
constructor in the Canvas. This background color is overridden by the
View anyway, so having it there was only confusing.
I do not have OSMesa on my main development platform, so I missed updating
some of the code when I changed the interface.
Also removed some inline statements on pure virtual functions that GCC
was complaining about.
Most of the time, you just match the WorldAnnotator with the canvas of
the same type. Rather than make the user specify it every time, add a
method to the canvas that creates a "good" WorldAnnotator to use with
it. Then, if a WorldAnnotator is not given to the View constructor, one
is automatically created from the Canvas.
The template parameters on vtkm::rendering::View are unnecessary. All
three of the templated classes are polymorphic (with virtual functions).
Thus, you just have to specify them at the constructor. Removing the
template parameters makes the syntax a bit cleaner and removes some
unnecessary duplication in the executable.
Removing the template does mean we cannot optimize in the future.
However, I expect us to start using more virtual methods rather than
less, so I think this is a move in the right direction.
Move some of the management of the width, height, and buffers to the base
Canvas class. Also, when it makes sense, get the width and height from
the rendering system.
Also changed the color buffer to be a Vec so that you don't have to
manage array offsets by hand.
All of these changes snowballed from the observation that the glut
example did not properly enable the depth buffer.
The word surface is more often used for something like a polygonal mesh,
so this name is quite confusing. Canvas is consistent with a
conventional name in GUI widget APIs.
