Commit Graph

14 Commits

Author SHA1 Message Date
Matt Larsen
bee6868254 Fixing the include in the rendering library 2017-02-09 12:36:59 -08:00
Dave Pugmire
db522c4cd1 Add GetCanvas calls to the mapper classes. 2016-11-28 09:41:01 -05:00
Dave Pugmire
87b1cdcacf cleanup. Remove some compiler warnings. 2016-11-23 13:45:03 -05:00
Kenneth Moreland
fdaccc22db Remove exports for header-only functions/methods
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.
2016-11-15 22:22:13 -07:00
Robert Maynard
7d295de8c9 Refactor vtk-m symbol visibility macros to be on the classes.
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.
2016-10-19 15:01:32 -04:00
Kenneth Moreland
22c6741152 Add View to rendering library
To get rid of some templates, I added the ability to create new
instances of mappers and canvases without knowing their type.
2016-09-07 16:48:04 -06:00
Kenneth Moreland
668f93a66b Move Mappers to rendering library
Also changed the mappers to not be templated on the device adapter.
Instead, use TryExecute to determine the device adapter at runtime.
2016-09-07 16:47:52 -06:00
Kenneth Moreland
303b4da4c8 Remove BackgroundColor from Mapper
This was supposed to be removed in an earlier commit where the
background color was consolidated to Canvas, but I missed this one.
2016-06-14 14:18:21 -06:00
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
Kenneth Moreland
9b34f9eccc Perform missing updates to OSMesa code
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.
2016-06-09 12:35:59 -06:00
Kenneth Moreland
0769b96bf3 Remove Width and Height from Camera
The width and height are maintained out of necessity by the canvas. A
second copy was maintained by the camera, which was only used for
computing the aspect ratio and similar metrics for projections.

Having to maintain the width/height in two places is a bit of a hassle
and provides the opportunity for bugs if they get out of sync. Instead,
have the width/height managed in one place (the canvas) and pass them as
parameters as necessary.
2016-06-09 12:07:56 -06:00
Kenneth Moreland
e30607f134 Hide internal std::vector in Scene
Generally we try not to expose the implementation details of how things
are stored in objects.

Also changed some arguments that should have been declared const to
actually be const.
2016-06-09 12:07:53 -06:00
Kenneth Moreland
fa3e43fbaa Change vtkm::rendering::RenderSurface to Canvas
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.
2016-06-02 16:04:13 -06:00
Kenneth Moreland
9fc86890eb Change vtkm::rendering::SceneRenderer* to Mapper*
This name was chosen to reflect the analogous name in VTK.
2016-06-02 13:41:14 -06:00