Kenneth Moreland 72b43d7151 Consolidate background color in rendering 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.		2016-06-11 12:09:51 -06:00
..
clipping	fixing another mention of field::order	2016-03-23 11:14:55 -04:00
demo	Change vtkm::rendering::RenderSurface to Canvas	2016-06-02 16:04:13 -06:00
hello_world	Make sure all source files are declared in the examples	2016-06-02 10:24:21 -06:00
isosurface	Make sure all source files are declared in the examples	2016-06-02 10:24:21 -06:00
lots_of_args	Do not add c++ compiler optimizations to all compilers, but on a target basis.	2016-01-25 14:38:06 -05:00
multi_backend	All examples now use the proper CMake CUDA found variable.	2016-02-22 11:25:15 -05:00
rendering	Consolidate background color in rendering classes	2016-06-11 12:09:51 -06:00
streamline	found more uses of field::order to remove.	2016-03-23 12:57:05 -04:00
tetrahedra	removing cell set dimensionality and splitting tetrahedralizer.	2016-05-13 14:26:59 -04:00
CMakeLists.txt	Add glut-based rendering example.	2016-05-05 13:26:39 -04:00