https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Jeff&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T00:57:33ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2014&diff=55148VTK/GSoC 20142014-02-13T16:15:41Z<p>Jeff: /* Project: Supporting a Visualization Grammar */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2013<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you should contact the community members identified below to find out more about the idea, get to know the community member that will review your proposal, and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors, and ideally have submitted a patch or two to fix bugs in their project (through Gerrit). Kitware makes extensive use of mailing lists, and this would be your best point of initial contact to apply for any of the proposed projects. The mailing lists can be found on the project pages linked in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea<br />
* Expected results/feature additions<br />
* Any prerequisites for working on the project<br />
* Links to any further information, discussions, bug reports etc<br />
* Any special mailing lists if not the standard mailing list for VTK<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor)<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: Biochemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for biochemistry visualization. VTK has already been used in several open source biochemistry applications, but only has limited support for protein ribbons. This would build on previous work done in chemistry. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here. This could also make use of existing work in infovis and 2D charting to display numerical data associated with biochemistry and bioinformatics applications. Looking at the boundary between quantum calculations and molecular dynamics, with QMMM data and other output ideally. <br />
<br />
'''Expected results:''' Support for standard biochemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK and/or OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Supporting a Visualization Grammar ===<br />
<br />
'''Brief explanation:''' Visualization grammars like [http://trifacta.github.com/vega Vega] are new declarative techniques for rendering arbitrary visualizations by mapping data attributes to visual properties. This project would provide a baseline implementation of a visualization grammar in VTK, combining rapid prototyping of visualizations with the graphical power and OpenGL performance of VTK.<br />
<br />
'''Expected results:''' The result would be VTK classes to support a grammar such as Vega that for example supports that JSON specification completely or a significant subset. Features would include grammar mark implementations in VTK/OpenGL, data specification and mapping to VTK data objects like vtkTable, and infrastructure for custom interaction binding. A scripting language such as VTKPython could be potentially utilized to drive grammar creation and generation.<br />
<br />
'''Prerequisites:''' C++ experience required, Javascript and Python experience a plus.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff dot baumes at kitware dot com).<br />
<br />
=== Biocomputing In Situ Visualization ===<br />
<br />
'''Brief explanation:''' Biocomputing involves using computer simulations to study biological problems. Of particular interest is [[http://www.gromacs.org/ GROMACS]], a versatile package to perform molecular dynamics, i.e. simulate the Newtonian equations of motion for systems with hundreds to millions of particles. It is primarily designed for biochemical molecules like proteins, lipids and nucleic acids that have a lot of complicated bonded interactions. GROMACS is optimized to run on distributed memory clusters with recent support for GPU and SSE optimization. These GROMACS supercomputing simulations produce enormous (terabytes) file output to be analyzed post process by tools that only read the trajectory (position, velocity, and forces) or coordinate (molecular structure) information, and simply guess at the topology rather than using the simulations topology defined in GROMACS.<br />
<br />
This project would provide a baseline implementation of ParaView Catalyst for molecular in situ visualization and data analysis embedded in GROMACS based on GROMACS' computed topology and trajectory information.<br />
<br />
'''Expected results:''' The result would be ParaView Catalyst adaptors, example python scripts, and new advanced visualization techniques for GROMACS in order to enhance the biocomputing workflow.<br />
<br />
'''Prerequisites:''' C++ and python experience required, some experience with VTK and ParaView ideally, but not required.<br />
<br />
'''Mentor:''' Patrick O'Leary (patrick dot oleary at kitware dot com).<br />
<br />
=== CAD Model and Simulation Spline Visualization ===<br />
<br />
'''Brief explanation''': While spline curves and surfaces have been used for many years to describe CAD models, these flexible representations have often been discarded during the meshing and simulation process that is used to estimate the behavior of CAD-modeled parts in a particular environment or during a particular event. Recently, a group of techniques called IsoGeometric Analysis (IGA) has evolved in order to reduce the amount of work required to prepare simulations and to improve their accuracy. This project would develop support for arbitrary-dimensional, rational spline patches in VTK so that these simulations can be visualized properly. This may involve conversion to handle the variety of spline formats (T-Splines, NURBS, Catmull-Clark surfaces, etc.).<br />
<br />
'''Expected results:''' The result would be a new mesh representation class, a reader, and a suite of 2-3 filters for contouring, cutting, and rendering these meshes.<br />
<br />
'''Prerequisites:''' C/C++ experience, knowledge of rational splines and techniques for processing them (degree elevation, knot insertion/removal), and preferably some experience with VTK<br />
<br />
'''Mentor(s):''' David Thompson (david dot thompson ta kitware dot com) and/or Bob O'Bara (bob dot obara ta kitware dot com)<br />
<br />
=== Shared Memory Parallelism in VTK ===<br />
<br />
'''Brief explanation''': Development of multi-threaded algorithms in VTK. Multiple R&D efforts are leading the creation of an infrastructure to support next generation multi-threaded parallel algorithm development in VTK. These efforts are based on modern parallel libraries such as Intel TBB and Inria KAAPI. The main goal of this project will be the development of algorithms that leverage this infrastructure. The focus will be on upgrading existing core algorithms such as iso-surfacing, clipping, cutting, warping etc. to be parallel.<br />
<br />
'''Expected results''': A number of algorithms that execute in parallel using shared memory. Scalability of new algorithms will have to be measured and documented. Development of regression tests and examples will be also expected.<br />
<br />
'''Prerequisites''': Experience in C++ and multi-threaded code development. Understanding of core visualization algorithms and data structures. Some experience in VTK ideally but not necessary.<br />
<br />
'''Mentor''': Berk Geveci (berk dot geveci at kitware dot com)<br />
<br />
=== Climate and Geo-spatial data visualization in VTK ===<br />
'''Brief explanation''': Observations show that global climate is changing and poses a serious challenge for cities around the world. The goal of this project to enhance VTK to support climate and other geospatial data visualizations which will enable the visualization community to create effective and powerful geo-informatics for urban-planners, policy-makers, farmers, and all other stakeholders to assess climate change and its impact on future environmental conditions for their region. <br />
<br />
'''Expected results''': The result would be VTK classes to support interactive climate and geo-spatial data visualizations, combining data from various geospatial and climate data sources such as from NASA, NOAA, and DOE, and exporting data in convenient formats such as CSV, Shapefile, GeoTIFF, PNG, Or JPEG. Development of a prototype using new functionality will also be expected. <br />
<br />
'''Prerequisites''': C++ experience required<br />
<br />
'''Mentor''': Aashish Chaudhary (aashish dot chaudhary at kitware dot com).<br />
<br />
=== Project: Improving Hardware Transparency Support in VTK ===<br />
<br />
'''Brief explanation:''' VTK's currently uses a depth peeling approach to provide support for transparency. Though its current implementation produces acceptable results it currently supports a limited range of graphics accelerators. This effort will investigate providing transparency support in VTK for a much larger range of hardware.<br />
<br />
'''Expected results:''' Integrating a transparency mechanism in VTK that will support both NVidia and ATI GPUs.<br />
<br />
'''Prerequisites:''' Experience in C++, OpenGL, GPU programing and understanding of core visualization algorithms and data structures. Some experience in VTK ideal but not necessary.<br />
<br />
'''Mentor:''' Bob O'Bara (bob dot obara at kitware dot com).<br />
<br />
=== Project: Improving Hardware Volume Rendering Support in VTK ===<br />
<br />
'''Brief explanation:''' Though its current implementation produces acceptable results VTK's GPU-based volume rendering approach currently supports a limited range of graphics accelerators. This effort will investigate providing GPU-assisted volume rendering support in VTK for a much larger range of hardware.<br />
<br />
'''Expected results:''' Integrating a GPU-assisted Volume rendering mechanism in VTK that will support both NVidia and ATI GPUs.<br />
<br />
'''Prerequisites:''' Experience in C++, OpenGL, GPU programing and understanding of core volume rendering algorithms and data structures. Some experience in VTK ideal but not necessary.<br />
<br />
'''Mentor:''' Bob O'Bara (bob dot obara at kitware dot com).<br />
<br />
=== Project: Improving Advanced Edge Rendering Support in VTK ===<br />
<br />
'''Brief explanation:''' Wireframe and Edge rendering is important for several applications, including CAD, solid modeling, non-photorealistic rendering, and technical illustration. Rendering the wireframe is important for revealing structural information of the underlying mesh used to model the object. This is especially true in scientific visualization of models submitted to numerical simulations, where the quality of the mesh is of great significance and thus has to be inspected. This project would investigate advance edge rendering techniques such as texture-based rendering for meshed surfaces.<br />
<br />
'''Expected results:''' Integrating an advanced edge rendering mechanism in VTK.<br />
<br />
'''Prerequisites:''' Experience in C++, OpenGL, GPU programing and understanding of core visualization algorithms and data structures. Some experience in VTK ideal but not necessary.<br />
<br />
'''Mentor:''' Bob O'Bara (bob dot obara at kitware dot com).<br />
<br />
=== Project: Supporting Solid Model Geometry in VTK ===<br />
<br />
'''Brief explanation:''' Traditionally VTK has addressed the visualization needs of post-processed simulation information. Typically in these cases a tessellated mesh represents the geometric domain. This project will extend VTK's role in the simulation lifecycle by investigating approaches that will enable VTK to visualize the parametric boundary representation information used in solid modeling kernels such as CGM and OpenCASCADE, which is typical pre-processing description of the geometric domain.<br />
<br />
'''Expected results:''' A VTK module that interfaces with one or more solid modeling kernels.<br />
<br />
'''Prerequisites:''' Experience in C++, and data structures. Some experience in VTK, parametric surfaces and solid modeling kernels ideal but not necessary.<br />
<br />
'''Mentor:''' Bob O'Bara (bob dot obara at kitware dot com).<br />
<br />
=== Project: Cloud Enabled Remote VTK Process ===<br />
<br />
'''Brief explanation:''' VTK has a powerful suite of processing and visualization filters and has support for distributed or HPC environments at a low level. However, web and cloud based processing has typically been addressed at a higher level using applications such as [http://www.paraview.org/Wiki/ParaViewWeb ParaViewWeb]. This project will enable web and cloud processing directly in VTK using the python wrapped VTK engine. The resulting application will need to interact with [http://ipython.org/notebook.html IPython Notebooks] to accept user commands and will need to interact with data sources such as JSON, XML and web hosted files/databases for input and output. The benefits of this application are three-fold. First, this will encourage reproducible research by enabling the sharing of the specific algorithms and data. Second, this will enable transparent migration of VTK code from a local installation to the cloud as problem sizes increase. And third, this becomes a powerful teaching tool for algorithms in 3D computer graphics, image processing and visualization.<br />
<br />
'''Expected results:''' A VTK/python based application suitable for cloud processing of distributed data resources.<br />
<br />
'''Prerequisites:''' Experience in web development, C++, VTK, and Python.<br />
<br />
'''Mentor:''' Wes Turner (wes dot turner at kitware dot com).<br />
<br />
=== Project: In Situ Analysis of Large-Scale AMR-Based Cosmological Simulations ===<br />
<br />
'''Brief explanation:''' In Situ analysis is an effective technique to analyze data from large-scale simulations and alleviate the I/O limitations and performance bottlenecks. During the past year, an in situ analysis framework targeting large-scale cosmological simulations, called CosmologyTools [http://public.kitware.com/gitweb?p=cosmologytools.git], has been developed. The framework currently supports N-Body particle-based simulations. However, a lot of cosmology simulation codes utilize an AMR discretization to incorporate additional physics, such as hydrodynamics.<br />
<br />
This project is geared towards extending the CosmologyTools framework to support AMR-based simulations. Of particular interest are, the FLASH [http://flash.uchicago.edu/site/] and Nyx [https://ccse.lbl.gov/Research/NYX/] simulation codes. <br />
<br />
'''Expected results:''' Expected results from this project are the following: (a) Extension of the CosmologyTools interface for AMR, (b) coupling with either FLASH or Nyx, (c) developing an in situ AMR-based analysis algorithm, such as, FFT or feature extraction and (d) wrapping the algorithm within the ParaView plugins provided in CosmologyTools.<br />
<br />
'''Prerequisites:''' C/C++ knowledge required. Experience with working on distributed memory architectures and MPI would be ideal, but, it is not required. Willingness to work hard and produce results with scientific impact.<br />
<br />
'''Mentor:''' George Zagaris (george dot zagaris at kitware dot com).</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2013&diff=51901VTK/GSoC 20132013-03-20T17:40:08Z<p>Jeff: /* Project: Supporting a Visualization Grammar */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2013<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you should contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and ideally have submitted a patch or two to fix bugs in the project they intend to work (through Gerrit). Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea<br />
* Expected results/feature additions<br />
* Any prerequisites for working on the project<br />
* Links to any further information, discussions, bug reports etc<br />
* Any special mailing lists if not the standard mailing list for the VTK<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor)<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: Biochemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for biochemistry visualization. VTK has already been used in several open source biochemistry applications, but only has limited support for protein ribbons. This would build on previous work done in chemistry. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here. This could also make use of existing work in infovis and 2D charting to display numerical data associated with biochemistry and bioinformatics applications. Looking at the boundary between quantum calculations and molecular dynamics, with QMMM data and other output ideally. <br />
<br />
'''Expected results:''' Support for standard biochemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK and/or OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Supporting a Visualization Grammar ===<br />
<br />
'''Brief explanation:''' Visualization grammars like [http://protovis.org Protovis] and the upcoming [http://trifacta.github.com/vega Vega] are new declarative techniques for rendering arbitrary visualizations by mapping data attributes to visual properties. This project would provide a baseline implementation of a visualization grammar in VTK, combining rapid prototyping of visualizations with the graphical power and OpenGL performance of VTK.<br />
<br />
'''Expected results:''' The result would be VTK classes to support a grammar such as Vega that for example supports that JSON specification completely or a significant subset. Features would include grammar mark implementations in VTK/OpenGL, data specification and mapping to VTK data objects like vtkTable, and infrastructure for custom interaction binding.<br />
<br />
'''Prerequisites:''' C++ experience required, Javascript experience a plus.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff dot baumes at kitware dot com).</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2013&diff=51900VTK/GSoC 20132013-03-20T17:39:24Z<p>Jeff: /* Project Ideas */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2013<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you should contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and ideally have submitted a patch or two to fix bugs in the project they intend to work (through Gerrit). Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea<br />
* Expected results/feature additions<br />
* Any prerequisites for working on the project<br />
* Links to any further information, discussions, bug reports etc<br />
* Any special mailing lists if not the standard mailing list for the VTK<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor)<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: Biochemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for biochemistry visualization. VTK has already been used in several open source biochemistry applications, but only has limited support for protein ribbons. This would build on previous work done in chemistry. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here. This could also make use of existing work in infovis and 2D charting to display numerical data associated with biochemistry and bioinformatics applications. Looking at the boundary between quantum calculations and molecular dynamics, with QMMM data and other output ideally. <br />
<br />
'''Expected results:''' Support for standard biochemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK and/or OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Supporting a Visualization Grammar ===<br />
<br />
'''Brief explanation:''' Visualization grammars like [http://protovis.org Protovis] and the upcoming [http://trifacta.github.com/vega Vega] are new declarative techniques for rendering arbitrary visualizations by mapping data attributes to visual properties. This project would provide a baseline implementation of a visualization grammar in VTK, combining rapid prototyping of visualizations with the graphical power and OpenGL performance of VTK.<br />
<br />
'''Expected results:''' The result would be VTK classes to support a grammar such as Vega that for example supports that JSON specification completely or a significant subset. Features would include grammar mark implementations in VTK/OpenGL, data specification and mapping to VTK data objects like vtkTable, custom interaction binding.<br />
<br />
'''Prerequisites:''' C++ experience required, Javascript experience a plus.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff dot baumes at kitware dot com).</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42346VTK/Java Wrapping2011-08-19T19:59:15Z<p>Jeff: /* Configuration */</p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Windows ===<br />
<br />
To run a sample application provided in VTK against your VTK build directory (with an installed VTK remove "Debug"):<br />
<br />
$ set PATH=%PATH%;your_vtk_build_dir\bin\Debug<br />
$ java -cp your_vtk_build_dir\bin\vtk.jar vtk.sample.Demo<br />
<br />
=== Mac ===<br />
<br />
To run a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar vtk.sample.Demo<br />
<br />
=== Linux ===<br />
<br />
To run a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. A button allows you to close the<br />
* application.<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
Some key points from this code to note:<br />
* vtkNativeLibrary.LoadAllNativeLibraries() is required to load the dynamic libraries from VTK's C++ core. This call must happen before any VTK code executes, which is why it is put in a static block in our application class.<br />
* vtkNativeLibrary.DisableOutputWindow(null) simply hides any debugging information that may otherwise pop up in a dialog box when any warnings are reached. This is good to call when releasing an application.<br />
* SwingUtilities.invokeLater(...) is called because technically all GUI code, including setting up and using a VTK render window, should happen in the Swing event thread.<br />
<br />
== Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) ==<br />
<br />
In this demo, we want to illustrate the correct way to perform VTK tasks on separate threads in Java. The first thing to note is that VTK is inherently NOT thread-safe, which immediately rules out several possible use cases. Calling methods on the same VTK objects across threads, even if they seem to be read-only, should be avoided. The safest approach is to "hand off" objects from one thread to another, so one thread is completely done with an object before another thread begins manipulating it. Reclaiming memory for VTK objects is particularly tricky to perform across threads, as deleting a single VTK object may potentially cause the entirety of VTK objects to be modified. While we expose the Delete() method to explicitly delete VTK objects, if you are using VTK objects in multiple threads this is discouraged unless you are aware of its potential issues. VTK provides a special garbage collector for VTK objects in the Java layer that may be run manually or automatically at intervals if memory reclaiming is needed.<br />
<br />
For this example, we will have a checkbox for turning on and off the VTK garbage collection while an application is running. The application creates new actors using a separate processing thread, which are then added dynamically to the VTK renderer. This enables data to be loaded and processed without causing lags in the frame rate of the interactive 3D view.<br />
<br />
We need to implement a worker that is capable of producing actors. In the sample code we produce<br />
sphere actors with shrunk polygons in order to have something interesting that takes a bit of time to create. These will execute on separate threads to keep the rendering interactive.<br />
<source lang="java"><br />
public static class PipelineBuilder implements Callable<vtkActor> {<br />
private vtkActor actor;<br />
...<br />
@Override<br />
public vtkActor call() throws Exception {<br />
// Set up a new actor<br />
actor = new vtkActor();<br />
...<br />
// Wait some time for other thread to work<br />
Thread.sleep((long) (Math.random() * 500));<br />
// Return<br />
return actor;<br />
}<br />
}<br />
</source><br />
<br />
A separate worker's job is to add actors to the renderer when ready.<br />
<source lang="java"><br />
public static class AddActorRunnable implements Runnable {<br />
private vtkActor actorToAdd;<br />
private vtkRenderer renderer;<br />
private vtkPanel panel;<br />
<br />
void setRenderer(vtkPanel panel) {<br />
this.renderer = panel.GetRenderer();<br />
this.panel = panel;<br />
}<br />
<br />
void setActor(vtkActor a) {<br />
this.actorToAdd = a;<br />
}<br />
<br />
@Override<br />
public void run() {<br />
this.renderer.AddActor(this.actorToAdd);<br />
this.panel.Render();<br />
}<br />
}<br />
</source><br />
<br />
In our initialization code, we need to set up several things. First, two checkboxes toggle VTK's garbage collection and the debug mode. Since VTK is a C++ library, it has its own mechanism for ensuring that unused objects are deleted from memory. Many threading issues can be avoided by simply turning off VTK garbage collection.<br />
<br />
<source lang="java"><br />
runGC = new JCheckBox("Enable GC", false);<br />
debugMode = new JCheckBox("Debug mode", false);<br />
</source><br />
<br />
We need to set up our completion service.<br />
<source lang="java"><br />
exec = new ExecutorCompletionService<vtkActor>(Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()));<br />
</source><br />
<br />
Next a setupWorkers() method starts a thread which invokes the code to add actors to the renderer whenever our executor completion service has a new actor available. Note that the code adding the actors to the renderer must be done on the event thread using SwingUtilities.invokeAndWait(), since that is where the renderer object was created and lives.<br />
<source lang="java"><br />
private void setupWorkers() {<br />
// Add actor thread: Consume the working queue and add the actor into<br />
// the render inside the EDT thread<br />
final AddActorRunnable adderRunnable = new AddActorRunnable();<br />
adderRunnable.setRenderer(panel3d);<br />
new Thread() {<br />
public void run() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
try {<br />
adderRunnable.setActor(exec.take().get());<br />
SwingUtilities.invokeAndWait(adderRunnable);<br />
panel3d.repaint();<br />
} catch (InterruptedException e) {<br />
return;<br />
} catch (ExecutionException e) {<br />
e.printStackTrace();<br />
} catch (InvocationTargetException e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
};<br />
}.start();<br />
}<br />
</source><br />
<br />
To load the completion service with jobs to run on a pool of threads in the background, we submit a collection of PipelineBuilder objects to be executed at a later time.<br />
<br />
<source lang="java"><br />
public void startWorking() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
exec.submit(new PipelineBuilder());<br />
}<br />
}<br />
</source><br />
<br />
We'll also create a timer which every second renders the scene and takes out a sphere actor. This code also manually run the garbage collector using vtkObject.JAVA_OBJECT_MANAGER.gc() if the runGC checkbox is selected. Note that timers are scheduled on the Swing event thread, which is why we are allowed to manipulate the renderer and its actors here. We call the garbage collector manually in order to update the UI with garbage collector information.<br />
<br />
<source lang="java"><br />
// Update GC info into the UI every second.<br />
// Reset camera each of the first 10 seconds.<br />
this.nbSeconds = 0;<br />
new Timer(1000, new ActionListener() {<br />
<br />
@Override<br />
public void actionPerformed(ActionEvent e) {<br />
if (nbSeconds++ < 10) {<br />
panel3d.resetCamera();<br />
}<br />
vtkRenderer renderer = panel3d.GetRenderer();<br />
if (renderer.GetNumberOfPropsRendered() > 1) {<br />
renderer.RemoveActor(renderer.GetActors().GetLastProp());<br />
}<br />
<br />
// Run GC in local thread (EDT)<br />
if (runGC.isSelected()) {<br />
vtkReferenceInformation info = vtkObject.JAVA_OBJECT_MANAGER.gc(debugMode.isSelected());<br />
if (debugMode.isSelected()) {<br />
System.out.println(info.listKeptReferenceToString());<br />
System.out.println(info.listRemovedReferenceToString());<br />
}<br />
gcStatus.setText(info.toString());<br />
} else {<br />
gcStatus.setText("");<br />
}<br />
<br />
panel3d.Render();<br />
}<br />
}).start();<br />
</source><br />
<br />
Instead of manually running the garbage collector, we can set up automatic garbage collection using a global scheduler. Turn on automatic garbage collection with the following statement. It is important to note that by default it is off, so be sure to include this line to reclaim memory from the VTK layer.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetAutoGarbageCollection(true);<br />
</source><br />
<br />
To set up the interval at which collection runs, use SetScheduleTime. In this case it will run garbage collection every second. The automatic garbage collector runs in the event thread by default.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetScheduleTime(1, TimeUnit.SECONDS);<br />
</source><br />
<br />
Another option will collect statistics on the garbage collector, that can be retrieved by listKeptReferenceToString() and listRemovedReferenceToString() on the collector's information object returned from the gc() method.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetDebug(true);<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42345VTK/Java Wrapping2011-08-19T19:50:10Z<p>Jeff: /* Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) */</p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. A button allows you to close the<br />
* application.<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
Some key points from this code to note:<br />
* vtkNativeLibrary.LoadAllNativeLibraries() is required to load the dynamic libraries from VTK's C++ core. This call must happen before any VTK code executes, which is why it is put in a static block in our application class.<br />
* vtkNativeLibrary.DisableOutputWindow(null) simply hides any debugging information that may otherwise pop up in a dialog box when any warnings are reached. This is good to call when releasing an application.<br />
* SwingUtilities.invokeLater(...) is called because technically all GUI code, including setting up and using a VTK render window, should happen in the Swing event thread.<br />
<br />
== Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) ==<br />
<br />
In this demo, we want to illustrate the correct way to perform VTK tasks on separate threads in Java. The first thing to note is that VTK is inherently NOT thread-safe, which immediately rules out several possible use cases. Calling methods on the same VTK objects across threads, even if they seem to be read-only, should be avoided. The safest approach is to "hand off" objects from one thread to another, so one thread is completely done with an object before another thread begins manipulating it. Reclaiming memory for VTK objects is particularly tricky to perform across threads, as deleting a single VTK object may potentially cause the entirety of VTK objects to be modified. While we expose the Delete() method to explicitly delete VTK objects, if you are using VTK objects in multiple threads this is discouraged unless you are aware of its potential issues. VTK provides a special garbage collector for VTK objects in the Java layer that may be run manually or automatically at intervals if memory reclaiming is needed.<br />
<br />
For this example, we will have a checkbox for turning on and off the VTK garbage collection while an application is running. The application creates new actors using a separate processing thread, which are then added dynamically to the VTK renderer. This enables data to be loaded and processed without causing lags in the frame rate of the interactive 3D view.<br />
<br />
We need to implement a worker that is capable of producing actors. In the sample code we produce<br />
sphere actors with shrunk polygons in order to have something interesting that takes a bit of time to create. These will execute on separate threads to keep the rendering interactive.<br />
<source lang="java"><br />
public static class PipelineBuilder implements Callable<vtkActor> {<br />
private vtkActor actor;<br />
...<br />
@Override<br />
public vtkActor call() throws Exception {<br />
// Set up a new actor<br />
actor = new vtkActor();<br />
...<br />
// Wait some time for other thread to work<br />
Thread.sleep((long) (Math.random() * 500));<br />
// Return<br />
return actor;<br />
}<br />
}<br />
</source><br />
<br />
A separate worker's job is to add actors to the renderer when ready.<br />
<source lang="java"><br />
public static class AddActorRunnable implements Runnable {<br />
private vtkActor actorToAdd;<br />
private vtkRenderer renderer;<br />
private vtkPanel panel;<br />
<br />
void setRenderer(vtkPanel panel) {<br />
this.renderer = panel.GetRenderer();<br />
this.panel = panel;<br />
}<br />
<br />
void setActor(vtkActor a) {<br />
this.actorToAdd = a;<br />
}<br />
<br />
@Override<br />
public void run() {<br />
this.renderer.AddActor(this.actorToAdd);<br />
this.panel.Render();<br />
}<br />
}<br />
</source><br />
<br />
In our initialization code, we need to set up several things. First, two checkboxes toggle VTK's garbage collection and the debug mode. Since VTK is a C++ library, it has its own mechanism for ensuring that unused objects are deleted from memory. Many threading issues can be avoided by simply turning off VTK garbage collection.<br />
<br />
<source lang="java"><br />
runGC = new JCheckBox("Enable GC", false);<br />
debugMode = new JCheckBox("Debug mode", false);<br />
</source><br />
<br />
We need to set up our completion service.<br />
<source lang="java"><br />
exec = new ExecutorCompletionService<vtkActor>(Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()));<br />
</source><br />
<br />
Next a setupWorkers() method starts a thread which invokes the code to add actors to the renderer whenever our executor completion service has a new actor available. Note that the code adding the actors to the renderer must be done on the event thread using SwingUtilities.invokeAndWait(), since that is where the renderer object was created and lives.<br />
<source lang="java"><br />
private void setupWorkers() {<br />
// Add actor thread: Consume the working queue and add the actor into<br />
// the render inside the EDT thread<br />
final AddActorRunnable adderRunnable = new AddActorRunnable();<br />
adderRunnable.setRenderer(panel3d);<br />
new Thread() {<br />
public void run() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
try {<br />
adderRunnable.setActor(exec.take().get());<br />
SwingUtilities.invokeAndWait(adderRunnable);<br />
panel3d.repaint();<br />
} catch (InterruptedException e) {<br />
return;<br />
} catch (ExecutionException e) {<br />
e.printStackTrace();<br />
} catch (InvocationTargetException e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
};<br />
}.start();<br />
}<br />
</source><br />
<br />
To load the completion service with jobs to run on a pool of threads in the background, we submit a collection of PipelineBuilder objects to be executed at a later time.<br />
<br />
<source lang="java"><br />
public void startWorking() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
exec.submit(new PipelineBuilder());<br />
}<br />
}<br />
</source><br />
<br />
We'll also create a timer which every second renders the scene and takes out a sphere actor. This code also manually run the garbage collector using vtkObject.JAVA_OBJECT_MANAGER.gc() if the runGC checkbox is selected. Note that timers are scheduled on the Swing event thread, which is why we are allowed to manipulate the renderer and its actors here. We call the garbage collector manually in order to update the UI with garbage collector information.<br />
<br />
<source lang="java"><br />
// Update GC info into the UI every second.<br />
// Reset camera each of the first 10 seconds.<br />
this.nbSeconds = 0;<br />
new Timer(1000, new ActionListener() {<br />
<br />
@Override<br />
public void actionPerformed(ActionEvent e) {<br />
if (nbSeconds++ < 10) {<br />
panel3d.resetCamera();<br />
}<br />
vtkRenderer renderer = panel3d.GetRenderer();<br />
if (renderer.GetNumberOfPropsRendered() > 1) {<br />
renderer.RemoveActor(renderer.GetActors().GetLastProp());<br />
}<br />
<br />
// Run GC in local thread (EDT)<br />
if (runGC.isSelected()) {<br />
vtkReferenceInformation info = vtkObject.JAVA_OBJECT_MANAGER.gc(debugMode.isSelected());<br />
if (debugMode.isSelected()) {<br />
System.out.println(info.listKeptReferenceToString());<br />
System.out.println(info.listRemovedReferenceToString());<br />
}<br />
gcStatus.setText(info.toString());<br />
} else {<br />
gcStatus.setText("");<br />
}<br />
<br />
panel3d.Render();<br />
}<br />
}).start();<br />
</source><br />
<br />
Instead of manually running the garbage collector, we can set up automatic garbage collection using a global scheduler. Turn on automatic garbage collection with the following statement. It is important to note that by default it is off, so be sure to include this line to reclaim memory from the VTK layer.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetAutoGarbageCollection(true);<br />
</source><br />
<br />
To set up the interval at which collection runs, use SetScheduleTime. In this case it will run garbage collection every second. The automatic garbage collector runs in the event thread by default.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetScheduleTime(1, TimeUnit.SECONDS);<br />
</source><br />
<br />
Another option will collect statistics on the garbage collector, that can be retrieved by listKeptReferenceToString() and listRemovedReferenceToString() on the collector's information object returned from the gc() method.<br />
<br />
<source lang="java"><br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetDebug(true);<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42344VTK/Java Wrapping2011-08-19T19:14:58Z<p>Jeff: /* Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) */</p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. A button allows you to close the<br />
* application.<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
Some key points from this code to note:<br />
* vtkNativeLibrary.LoadAllNativeLibraries() is required to load the dynamic libraries from VTK's C++ core. This call must happen before any VTK code executes, which is why it is put in a static block in our application class.<br />
* vtkNativeLibrary.DisableOutputWindow(null) simply hides any debugging information that may otherwise pop up in a dialog box when any warnings are reached. This is good to call when releasing an application.<br />
* SwingUtilities.invokeLater(...) is called because technically all GUI code, including setting up and using a VTK render window, should happen in the Swing event thread.<br />
<br />
== Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) ==<br />
<br />
In this demo, we want to illustrate the correct way to perform VTK tasks on separate threads in Java. The first thing to note is that VTK is inherently NOT thread-safe, which immediately rules out several possible use cases. Calling methods on the same VTK objects across threads, even if they seem to be read-only, should be avoided. The safest approach is to "hand off" objects from one thread to another, so one thread is completely done with an object before another thread begins manipulating it. Reclaiming memory for VTK objects is particularly tricky to perform across threads, as deleting a single VTK object may potentially cause the entirety of VTK objects to be modified. While we expose the Delete() method to explicitly delete VTK objects, if you are using VTK objects in multiple threads this is discouraged. VTK provides a special garbage collector for VTK objects in the Java layer that may be run periodically is memory reclaiming is needed.<br />
<br />
For this example, we will have a checkbox for turning on and off the VTK garbage collection while an application is running. The application creates new actors using a separate processing thread, which are then added dynamically to the VTK renderer. This enables data to be loaded and processed without causing lags in the frame rate of the interactive 3D view.<br />
<br />
We need to implement a worker that is capable of producing actors. In the sample code we produce<br />
sphere actors with shrunk polygons in order to have something interesting that takes a bit of time to create.<br />
<source lang="java"><br />
public static class PipelineBuilder implements Callable<vtkActor> {<br />
private vtkActor actor;<br />
...<br />
@Override<br />
public vtkActor call() throws Exception {<br />
// Set up a new actor<br />
actor = new vtkActor();<br />
...<br />
// Wait some time for other thread to work<br />
Thread.sleep((long) (Math.random() * 500));<br />
// Return<br />
return actor;<br />
}<br />
}<br />
</source><br />
<br />
A separate worker's job is to add actors to the renderer when ready.<br />
<source lang="java"><br />
public static class AddActorRunnable implements Runnable {<br />
private vtkActor actorToAdd;<br />
private vtkRenderer renderer;<br />
private vtkPanel panel;<br />
<br />
void setRenderer(vtkPanel panel) {<br />
this.renderer = panel.GetRenderer();<br />
this.panel = panel;<br />
}<br />
<br />
void setActor(vtkActor a) {<br />
this.actorToAdd = a;<br />
}<br />
<br />
@Override<br />
public void run() {<br />
this.renderer.AddActor(this.actorToAdd);<br />
this.panel.Render();<br />
}<br />
}<br />
</source><br />
<br />
In our initialization code, we need to set up several things. First, two checkboxes toggle VTK's garbage collection and the debug mode. Since VTK is a C++ library, it has its own mechanism for ensuring that unused objects are deleted from memory. Many threading issues can be avoided by simply turning off VTK garbage collection.<br />
<br />
<source lang="java"><br />
runGC = new JCheckBox("Enable GC", false);<br />
debugMode = new JCheckBox("Debug mode", false);<br />
</source><br />
<br />
We need to set up our completion service.<br />
<source lang="java"><br />
exec = new ExecutorCompletionService<vtkActor>(Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()));<br />
</source><br />
<br />
Next a setupWorkers() method starts a thread which invokes the code to add actors to the renderer whenever our executor completion service has a new actor available. Note that the code adding the actors to the renderer must be done on the event thread using SwingUtilities.invokeAndWait(), since that is where the renderer object was created and lives.<br />
<source lang="java"><br />
private void setupWorkers() {<br />
// Add actor thread: Consume the working queue and add the actor into<br />
// the render inside the EDT thread<br />
final AddActorRunnable adderRunnable = new AddActorRunnable();<br />
adderRunnable.setRenderer(panel3d);<br />
new Thread() {<br />
public void run() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
try {<br />
adderRunnable.setActor(exec.take().get());<br />
SwingUtilities.invokeAndWait(adderRunnable);<br />
panel3d.repaint();<br />
} catch (InterruptedException e) {<br />
return;<br />
} catch (ExecutionException e) {<br />
e.printStackTrace();<br />
} catch (InvocationTargetException e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
};<br />
}.start();<br />
}<br />
</source><br />
<br />
We'll also create a timer which every second renders the scene and takes out a sphere actor. This code also manually run the garbage collector using vtkObject.JAVA_OBJECT_MANAGER.gc() if the runGC checkbox is selected. Note that timers are scheduled on the Swing event thread, which is why we are allowed to manipulate the renderer and its actors here.<br />
<br />
<source lang="java"><br />
// Update GC info into the UI every second.<br />
// Reset camera each of the first 10 seconds.<br />
this.nbSeconds = 0;<br />
new Timer(1000, new ActionListener() {<br />
<br />
@Override<br />
public void actionPerformed(ActionEvent e) {<br />
if (nbSeconds++ < 10) {<br />
panel3d.resetCamera();<br />
}<br />
vtkRenderer renderer = panel3d.GetRenderer();<br />
if (renderer.GetNumberOfPropsRendered() > 1) {<br />
renderer.RemoveActor(renderer.GetActors().GetLastProp());<br />
}<br />
<br />
// Run GC in local thread (EDT)<br />
if (runGC.isSelected()) {<br />
vtkReferenceInformation info = vtkObject.JAVA_OBJECT_MANAGER.gc(debugMode.isSelected());<br />
if (debugMode.isSelected()) {<br />
System.out.println(info.listKeptReferenceToString());<br />
System.out.println(info.listRemovedReferenceToString());<br />
}<br />
gcStatus.setText(info.toString());<br />
} else {<br />
gcStatus.setText("");<br />
}<br />
<br />
panel3d.Render();<br />
}<br />
}).start();<br />
</source><br />
<source lang="java"><br />
private void setupGC() {<br />
// Setup GC to run every 1 second in EDT<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetScheduleTime(1, TimeUnit.SECONDS);<br />
<br />
// Start/Stop the GC based on the checkbox<br />
runGC.addActionListener(new ActionListener() {<br />
@Override<br />
public void actionPerformed(ActionEvent arg0) {<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetAutoGarbageCollection(runGC.isSelected());<br />
}<br />
});<br />
<br />
// Change GC mode based on the checkbox<br />
debugMode.addActionListener(new ActionListener() {<br />
@Override<br />
public void actionPerformed(ActionEvent arg0) {<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetDebug(debugMode.isSelected());<br />
}<br />
});<br />
}<br />
</source><br />
<source lang="java"><br />
public void startWorking() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
exec.submit(new PipelineBuilder());<br />
}<br />
}<br />
</source><br />
<source lang="java"><br />
// -----------------------------------------------------------------<br />
public static void main(String[] args) throws InterruptedException, InvocationTargetException {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
Demo app = new Demo();<br />
<br />
JFrame f = new JFrame("Concurrency test");<br />
f.getContentPane().setLayout(new BorderLayout());<br />
f.getContentPane().add(app, BorderLayout.CENTER);<br />
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
f.setSize(400, 400);<br />
f.setVisible(true);<br />
f.validate();<br />
<br />
app.startWorking();<br />
}<br />
});<br />
}<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42341VTK/Java Wrapping2011-08-19T17:29:01Z<p>Jeff: /* Java Wrapper Refactoring (Oct 8, 2007) */</p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. A button allows you to close the<br />
* application.<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
Some key points from this code to note:<br />
* vtkNativeLibrary.LoadAllNativeLibraries() is required to load the dynamic libraries from VTK's C++ core. This call must happen before any VTK code executes, which is why it is put in a static block in our application class.<br />
* vtkNativeLibrary.DisableOutputWindow(null) simply hides any debugging information that may otherwise pop up in a dialog box when any warnings are reached. This is good to call when releasing an application.<br />
* SwingUtilities.invokeLater(...) is called because technically all GUI code, including setting up and using a VTK render window, should happen in the Swing event thread.<br />
<br />
== Threading Sample Code (from VTK/Wrapping/Java/vtk/sample/Demo.java) ==<br />
<br />
In this demo, we want to illustrate the correct way to perform VTK tasks on separate threads in Java. The first thing to note is that VTK is inherently NOT thread-safe, which immediately rules out several possible use cases. Calling methods on the same VTK objects across threads, even if they seem to be read-only, should be avoided. The safest approach is to "hand off" objects from one thread to another, so one thread is completely done with an object before another thread begins manipulating it. Reclaiming memory for VTK objects is particularly tricky to perform across threads, as deleting a single VTK object may potentially cause the entirety of VTK objects to be modified. While we expose the Delete() method to explicitly delete VTK objects, if you are using VTK objects in multiple threads this is discouraged. VTK provides a special garbage collector for VTK objects in the Java layer that may be run periodically is memory reclaiming is needed.<br />
<br />
For this example, we will have a checkbox for turning on and off the VTK garbage collection while an application is running. The application creates new actors using a separate processing thread, which are then added dynamically to the VTK renderer. This enables data to be loaded and processed without causing lags in the frame rate of the interactive 3D view.<br />
<br />
Our demo class will have a completion service which creates actors.<br />
<source lang="java"><br />
public class Demo extends JPanel {<br />
private final CompletionService<vtkActor> exec;<br />
</source><br />
<br />
We need to implement a worker that is capable of producing actors. In the sample code we produce<br />
sphere actors with shrunk polygons in otder to have something interesting.<br />
<source lang="java"><br />
// -----------------------------------------------------------------<br />
public static class PipelineBuilder implements Callable<vtkActor> {<br />
private vtkActor actor;<br />
...<br />
@Override<br />
public vtkActor call() throws Exception {<br />
// Set up a new actor<br />
actor = new vtkActor();<br />
...<br />
// Wait some time for other thread to work<br />
Thread.sleep((long) (Math.random() * 500));<br />
// Return<br />
return actor;<br />
}<br />
}<br />
</source><br />
<br />
A separate worker's job is to add actors to the renderer when ready.<br />
<source lang="java"><br />
public static class AddActorRunnable implements Runnable {<br />
private vtkActor actorToAdd;<br />
private vtkRenderer renderer;<br />
private vtkPanel panel;<br />
<br />
void setRenderer(vtkPanel panel) {<br />
this.renderer = panel.GetRenderer();<br />
this.panel = panel;<br />
}<br />
<br />
void setActor(vtkActor a) {<br />
this.actorToAdd = a;<br />
}<br />
<br />
@Override<br />
public void run() {<br />
this.renderer.AddActor(this.actorToAdd);<br />
this.panel.Render();<br />
}<br />
}<br />
</source><br />
<br />
In our constructor code, we need to set up several things. First, two checkboxes toggle VTK's garbage collection and the debug mode. Since VTK is a C++ library, it has its own mechanism for ensuring that unused objects are deleted from memory. Many threading issues can be avoided by simply turning off VTK garbage collection.<br />
<br />
<source lang="java"><br />
runGC = new JCheckBox("Enable GC", false);<br />
debugMode = new JCheckBox("Debug mode", false);<br />
</source><br />
<br />
We need to set up our completion service.<br />
<source lang="java"><br />
exec = new ExecutorCompletionService<vtkActor>(Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()));<br />
</source><br />
<br />
<br />
<source lang="java"><br />
// Init app<br />
// this.setupGC(); // We use a Swing timer that show the result in UI<br />
// instead..<br />
this.setupWorkers();<br />
</source><br />
<source lang="java"><br />
// Update GC info into the UI every seconds<br />
// Reset camera each seconds the first 10 ones<br />
this.nbSeconds = 0;<br />
new Timer(1000, new ActionListener() {<br />
<br />
@Override<br />
public void actionPerformed(ActionEvent e) {<br />
if (nbSeconds++ < 10) {<br />
panel3d.resetCamera();<br />
}<br />
vtkRenderer renderer = panel3d.GetRenderer();<br />
if (renderer.GetNumberOfPropsRendered() > 1) {<br />
renderer.RemoveActor(renderer.GetActors().GetLastProp());<br />
}<br />
<br />
// Run GC in local thread (EDT)<br />
if (runGC.isSelected()) {<br />
vtkReferenceInformation info = vtkObject.JAVA_OBJECT_MANAGER.gc(debugMode.isSelected());<br />
if (debugMode.isSelected()) {<br />
System.out.println(info.listKeptReferenceToString());<br />
System.out.println(info.listRemovedReferenceToString());<br />
}<br />
gcStatus.setText(info.toString());<br />
} else {<br />
gcStatus.setText("");<br />
}<br />
<br />
panel3d.Render();<br />
}<br />
}).start();<br />
</source><br />
<source lang="java"><br />
private void setupGC() {<br />
// Setup GC to run every 1 second in EDT<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetScheduleTime(1, TimeUnit.SECONDS);<br />
<br />
// Start/Stop the GC based on the checkbox<br />
runGC.addActionListener(new ActionListener() {<br />
@Override<br />
public void actionPerformed(ActionEvent arg0) {<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetAutoGarbageCollection(runGC.isSelected());<br />
}<br />
});<br />
<br />
// Change GC mode based on the checkbox<br />
debugMode.addActionListener(new ActionListener() {<br />
@Override<br />
public void actionPerformed(ActionEvent arg0) {<br />
vtkObject.JAVA_OBJECT_MANAGER.getAutoGarbageCollector().SetDebug(debugMode.isSelected());<br />
}<br />
});<br />
}<br />
</source><br />
<source lang="java"><br />
private void setupWorkers() {<br />
// Add actor thread: Consume the working queue and add the actor into<br />
// the render inside the EDT thread<br />
final AddActorRunnable adderRunnable = new AddActorRunnable();<br />
adderRunnable.setRenderer(panel3d);<br />
new Thread() {<br />
public void run() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
try {<br />
adderRunnable.setActor(exec.take().get());<br />
SwingUtilities.invokeAndWait(adderRunnable);<br />
panel3d.repaint();<br />
} catch (InterruptedException e) {<br />
return;<br />
} catch (ExecutionException e) {<br />
e.printStackTrace();<br />
} catch (InvocationTargetException e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
};<br />
}.start();<br />
}<br />
</source><br />
<source lang="java"><br />
public void startWorking() {<br />
for (int i = 0; i < NUMBER_OF_PIPLINE_TO_BUILD; i++) {<br />
exec.submit(new PipelineBuilder());<br />
}<br />
}<br />
</source><br />
<source lang="java"><br />
// -----------------------------------------------------------------<br />
public static void main(String[] args) throws InterruptedException, InvocationTargetException {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
Demo app = new Demo();<br />
<br />
JFrame f = new JFrame("Concurrency test");<br />
f.getContentPane().setLayout(new BorderLayout());<br />
f.getContentPane().add(app, BorderLayout.CENTER);<br />
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
f.setSize(400, 400);<br />
f.setVisible(true);<br />
f.validate();<br />
<br />
app.startWorking();<br />
}<br />
});<br />
}<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42340VTK/Java Wrapping2011-08-19T17:02:46Z<p>Jeff: </p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. A button allows you to close the<br />
* application.<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
Some key points from this code to note:<br />
* vtkNativeLibrary.LoadAllNativeLibraries() is required to load the dynamic libraries from VTK's C++ core. This call must happen before any VTK code executes, which is why it is put in a static block in our application class.<br />
* vtkNativeLibrary.DisableOutputWindow(null) simply hides any debugging information that may otherwise pop up in a dialog box when any warnings are reached. This is good to call when releasing an application.<br />
* SwingUtilities.invokeLater(...) is called because technically all GUI code, including setting up and using a VTK render window, should happen in the Swing event thread.<br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42316VTK/Java Wrapping2011-08-18T19:12:22Z<p>Jeff: /* Usage */</p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Sample Code (from VTK/Wrapping/Java/vtk/sample/SimpleVTK.java) ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. The button allow to close the<br />
* application<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Java_Wrapping&diff=42315VTK/Java Wrapping2011-08-18T19:09:06Z<p>Jeff: </p>
<hr />
<div>== Configuration ==<br />
<br />
You basically just need to turn VTK_WRAP_JAVA on in CMake and build.<br />
<br />
Bartlomiej Wilkowski has created a nice tutorial of [http://www.spinet.pl/~wilku/vtk-howto/ configuring Java wrapping with VTK].<br />
<br />
=== Mac (Snow Leopard) ===<br />
<br />
To build a sample application provided in VTK against your VTK build directory (with an installed VTK replace "bin" with "lib"):<br />
<br />
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:your_vtk_build_dir/bin<br />
$ javac -cp your_vtk_build_dir/bin/vtk.jar your_vtk_source_dir/Wrapping/Java/vtk/sample/Demo.java<br />
$ java -cp your_vtk_build_dir/bin/vtk.jar:your_vtk_source_dir/Wrapping/Java vtk.sample.Demo<br />
<br />
== Usage ==<br />
<br />
<source lang="java"><br />
/**<br />
* An application that displays a 3D cone. The button allow to close the<br />
* application<br />
*/<br />
public class SimpleVTK extends JPanel implements ActionListener {<br />
private static final long serialVersionUID = 1L;<br />
private vtkPanel renWin;<br />
private JButton exitButton;<br />
<br />
// -----------------------------------------------------------------<br />
// Load VTK library and print which library was not properly loaded<br />
static {<br />
if (!vtkNativeLibrary.LoadAllNativeLibraries()) {<br />
for (vtkNativeLibrary lib : vtkNativeLibrary.values()) {<br />
if (!lib.IsLoaded()) {<br />
System.out.println(lib.GetLibraryName() + " not loaded");<br />
}<br />
}<br />
}<br />
vtkNativeLibrary.DisableOutputWindow(null);<br />
}<br />
<br />
// -----------------------------------------------------------------<br />
public SimpleVTK() {<br />
super(new BorderLayout());<br />
<br />
// build VTK Pipeline<br />
vtkConeSource cone = new vtkConeSource();<br />
cone.SetResolution(8);<br />
<br />
vtkPolyDataMapper coneMapper = new vtkPolyDataMapper();<br />
coneMapper.SetInputConnection(cone.GetOutputPort());<br />
<br />
vtkActor coneActor = new vtkActor();<br />
coneActor.SetMapper(coneMapper);<br />
<br />
renWin = new vtkPanel();<br />
renWin.GetRenderer().AddActor(coneActor);<br />
<br />
// Add Java UI components<br />
exitButton = new JButton("Exit");<br />
exitButton.addActionListener(this);<br />
<br />
add(renWin, BorderLayout.CENTER);<br />
add(exitButton, BorderLayout.SOUTH);<br />
}<br />
<br />
/** An ActionListener that listens to the button. */<br />
public void actionPerformed(ActionEvent e) {<br />
if (e.getSource().equals(exitButton)) {<br />
System.exit(0);<br />
}<br />
}<br />
<br />
public static void main(String s[]) {<br />
SwingUtilities.invokeLater(new Runnable() {<br />
@Override<br />
public void run() {<br />
JFrame frame = new JFrame("SimpleVTK");<br />
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
frame.getContentPane().setLayout(new BorderLayout());<br />
frame.getContentPane().add(new SimpleVTK(), BorderLayout.CENTER);<br />
frame.setSize(400, 400);<br />
frame.setLocationRelativeTo(null);<br />
frame.setVisible(true);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
<br />
== Java Wrapper Refactoring (Oct 8, 2007) ==<br />
<br />
There were a few problems with the old Java wrappers. One was that, as<br />
you said, objects were being deleted before they were supposed to. We<br />
hacked in a fix at one point about a year ago which basically made all<br />
VTK objects accessed from Java stay around forever, but this was not<br />
acceptable either.<br />
<br />
Ref:<br />
* http://vtk.org/cgi-bin/viewcvs.cgi/Wrapping/vtkWrapJava.c?r1=1.59&r2=1.60<br />
<br />
The other major concern was that the map from Java objects to VTK<br />
objects was in the C++ JNI layer, and while we tried to keep this map<br />
synchronized with a mutex, race conditions could still occur because<br />
other Java threads could advance while the JNI layer was being called<br />
(a thread could access a C++ object just as it is being<br />
garbage-collected and deleted). There does not seem to be a way to<br />
atomically call a JNI method, or ensure the collector doesn't run<br />
while a method is called. This second issue forced us to rethink how<br />
the map is done, and the solution was to keep the map in Java instead<br />
of C++. But we didn't want this Java map to prohibit objects from<br />
being garbage collected. Fortunately, Java has a WeakReference class<br />
for just this type of purpose. When accessed, the reference will<br />
either be valid or null depending on whether it has been<br />
garbage-collected.<br />
<br />
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html<br />
<br />
Thus, the wrapper code can lookup objects in this map when returning<br />
objects from methods, and if it is not there, or null, it creates a<br />
new Java object representing that C++ object.<br />
<br />
A final issue was that we wanted a way to guarantee all C++<br />
destructors are called before the program exits. The natural place to<br />
decrement the reference count of the C++ object is in finalize(),<br />
which works when things are garbage-collected, but Java does not<br />
guarantee that finalize will ever be called. So the method<br />
vtkGlobalJavaHash.DeleteAll() will plow through the remaining VTK<br />
objects and call Delete on them.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=41576VTK/ARB/Meetings2011-07-12T13:02:18Z<p>Jeff: /* Scheduled Meetings */</p>
<hr />
<div>== Scheduled Meetings ==<br />
* [[VTK/ARB/Meetings/July 2011|July 12, 2011]]<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/January 2011|January 18, 2011]]<br />
* [[VTK/ARB/Meetings/October 2010|October 6, 2010]]<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/June_2011&diff=41297VTK/ARB/Meetings/June 20112011-06-28T14:41:13Z<p>Jeff: /* Meeting Notes */</p>
<hr />
<div>== Time ==<br />
June 28th, 9am EDT<br />
<br />
== Agenda ==<br />
* VTK modularization update (Berk)<br />
* VTK 6 (Berk)<br />
* VTK backwards incompatible change to Python wrappers (Berk)<br />
<br />
The way the patch works is by disabling Register() and UnRegister() for<br />
any object generated by NewInstance() etc. For other objects, the<br />
Register/UnRegister methods work as before. That was the compromise<br />
that I reached between backwards compatibility and new functionality.<br />
<br />
Chopping those methods completely would be the best, this could be<br />
done for the VTK 6 release.<br />
<br />
As for handling all method that generate new objects, I had a brief on-list<br />
discussion about this with David Cole. I could modify the VTK wrappers to<br />
understand attribute-based hints similar to mummy/ActiVis:<br />
<br />
iwhCounted vtkObject *vtkObject::GeneratorMethod();<br />
<br />
The "iwhCounted" or something similarly named would be an attribute<br />
hint we would add to the header files to indicate object generation methods.<br />
Other attribute hints could eventually replace the Wrapping/hints file.<br />
<br />
== Meeting Notes ==<br />
<br />
* VTK 5.8 imminent<br />
* VTK 5.10 sometime later in the summer<br />
* VTK 6 in the fall<br />
* Postponing meeting since there is not a quorum.<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/June_2011&diff=41294VTK/ARB/Meetings/June 20112011-06-28T13:13:43Z<p>Jeff: /* Meeting Notes */</p>
<hr />
<div>== Time ==<br />
June 28th, 9am EDT<br />
<br />
== Agenda ==<br />
* VTK modularization update (Berk)<br />
* VTK 6 (Berk)<br />
* VTK backwards incompatible change to Python wrappers (Berk)<br />
<br />
The way the patch works is by disabling Register() and UnRegister() for<br />
any object generated by NewInstance() etc. For other objects, the<br />
Register/UnRegister methods work as before. That was the compromise<br />
that I reached between backwards compatibility and new functionality.<br />
<br />
Chopping those methods completely would be the best, this could be<br />
done for the VTK 6 release.<br />
<br />
As for handling all method that generate new objects, I had a brief on-list<br />
discussion about this with David Cole. I could modify the VTK wrappers to<br />
understand attribute-based hints similar to mummy/ActiVis:<br />
<br />
iwhCounted vtkObject *vtkObject::GeneratorMethod();<br />
<br />
The "iwhCounted" or something similarly named would be an attribute<br />
hint we would add to the header files to indicate object generation methods.<br />
Other attribute hints could eventually replace the Wrapping/hints file.<br />
<br />
== Meeting Notes ==<br />
<br />
* VTK 5.8 imminent<br />
* VTK 5.10 sometime later in the summer<br />
* VTK 6 in the fall<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/June_2011&diff=41291VTK/ARB/Meetings/June 20112011-06-28T12:48:22Z<p>Jeff: /* Agenda */</p>
<hr />
<div>== Time ==<br />
June 28th, 9am EDT<br />
<br />
== Agenda ==<br />
* VTK modularization update (Berk)<br />
* VTK 6 (Berk)<br />
* VTK backwards incompatible change to Python wrappers (Berk)<br />
<br />
The way the patch works is by disabling Register() and UnRegister() for<br />
any object generated by NewInstance() etc. For other objects, the<br />
Register/UnRegister methods work as before. That was the compromise<br />
that I reached between backwards compatibility and new functionality.<br />
<br />
Chopping those methods completely would be the best, this could be<br />
done for the VTK 6 release.<br />
<br />
As for handling all method that generate new objects, I had a brief on-list<br />
discussion about this with David Cole. I could modify the VTK wrappers to<br />
understand attribute-based hints similar to mummy/ActiVis:<br />
<br />
iwhCounted vtkObject *vtkObject::GeneratorMethod();<br />
<br />
The "iwhCounted" or something similarly named would be an attribute<br />
hint we would add to the header files to indicate object generation methods.<br />
Other attribute hints could eventually replace the Wrapping/hints file.<br />
<br />
== Meeting Notes ==<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/June_2011&diff=41283VTK/ARB/Meetings/June 20112011-06-28T11:40:52Z<p>Jeff: /* Agenda */</p>
<hr />
<div>== Time ==<br />
June 28th, 9am EDT<br />
<br />
== Agenda ==<br />
* VTK modularization update (Berk)<br />
* VTK 6 (Berk)<br />
* VTK backwards incompatible change to Python wrappers (Berk)<br />
<br />
== Meeting Notes ==<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/June_2011&diff=40527VTK/ARB/Meetings/June 20112011-06-09T15:08:10Z<p>Jeff: Created page with "== Time == June 28th, 9am EDT == Agenda == * VTK modularization update (Berk) * VTK 6 (Berk) == Meeting Notes == == Action Items == == Next Time =="</p>
<hr />
<div>== Time ==<br />
June 28th, 9am EDT<br />
<br />
== Agenda ==<br />
* VTK modularization update (Berk)<br />
* VTK 6 (Berk)<br />
<br />
== Meeting Notes ==<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=40526VTK/ARB/Meetings2011-06-09T15:06:31Z<p>Jeff: </p>
<hr />
<div>== Scheduled Meetings ==<br />
* [[VTK/ARB/Meetings/June 2011|June 28, 2011]]<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/January 2011|January 18, 2011]]<br />
* [[VTK/ARB/Meetings/October 2010|October 6, 2010]]<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38353VTK/GSoC 20112011-03-11T14:28:52Z<p>Jeff: /* Project: Protovis in C++ */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++. This project relies heavily on C++ libraries such as the boost::lambda library for inline lambda functions in order to write compact visualization descriptions.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++, boost and template programming a plus. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38352VTK/GSoC 20112011-03-11T14:25:54Z<p>Jeff: /* Project: Volume Rendering in O3D/WebGL */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38351VTK/GSoC 20112011-03-11T14:24:56Z<p>Jeff: </p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in O3D/WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in O3D and/or WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations O3D and/or WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/January_2011&diff=36519VTK/ARB/Meetings/January 20112011-01-18T19:08:46Z<p>Jeff: </p>
<hr />
<div>== Time ==<br />
January 18th, 1pm EDT<br />
<br />
== Agenda ==<br />
* Review action items from last time<br />
** Send any additional multi-threading use cases to Stephane.<br />
** Coordinate on setting up "modules" for VTK Journal (Bill and Will).<br />
* VTK release update<br />
* VTK reorganization update<br />
* VTK workflow (Berk)<br />
** ITK experiences with [http://review.source.kitware.com/#q,status:open,n,z Gerrit]<br />
<br />
== Meeting Notes ==<br />
* Release<br />
** Finishing VTK dashboard cleanup, release soon<br />
** New charting classes, widget tweaks<br />
** Migrate changes from Slicer to VTK master<br />
* Reorganization<br />
** Waiting until Feb.<br />
** Marcus Hanwell will do majority of reorg<br />
** Berk will work on separating algorithms from pipeline, changing behavior of SetInput() to not make a pipeline connection<br />
** There may be additional changes needed to the filter internals when this change happens<br />
* VTK workflow<br />
** More formal procedures needed for developing VTK, as in documentation<br />
** Consider using gerrit for code review<br />
** Run only tests that are impacted by a change<br />
** Do we need master/next if we have gerrit?<br />
** Caution against getting too formalized, you will have less involvement<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==<br />
* More about workflow</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/January_2011&diff=35838VTK/ARB/Meetings/January 20112010-12-21T14:07:31Z<p>Jeff: </p>
<hr />
<div>== Time ==<br />
January 18th, 1pm EDT<br />
<br />
== Agenda ==<br />
* Review action items from last time<br />
** Send any additional multi-threading use cases to Stephane.<br />
** Coordinate on setting up "modules" for VTK Journal (Bill and Will).<br />
* VTK release update<br />
* VTK reorganization update<br />
* VTK workflow (Berk)<br />
<br />
== Meeting Notes ==<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/January_2011&diff=35837VTK/ARB/Meetings/January 20112010-12-21T14:06:14Z<p>Jeff: Created page with "== Agenda == * Review action items from last time ** Send any additional multi-threading use cases to Stephane. ** Coordinate on setting up "modules" for VTK Journal (Bill and Wi..."</p>
<hr />
<div>== Agenda ==<br />
* Review action items from last time<br />
** Send any additional multi-threading use cases to Stephane.<br />
** Coordinate on setting up "modules" for VTK Journal (Bill and Will).<br />
* VTK release update<br />
* VTK reorganization update<br />
* VTK workflow (Berk)<br />
<br />
== Meeting Notes ==<br />
<br />
== Action Items ==<br />
<br />
== Next Time ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=35836VTK/ARB/Meetings2010-12-21T14:03:00Z<p>Jeff: </p>
<hr />
<div>== Scheduled Meetings ==<br />
* [[VTK/ARB/Meetings/January 2011|January 18, 2011]]<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/October 2010|October 6, 2010]]<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB&diff=33303VTK/ARB2010-10-26T22:11:29Z<p>Jeff: </p>
<hr />
<div>__NOTOC__<br />
==Purpose==<br />
<br />
The VTK Architecture Review Board (ARB) is a group of individuals whose goal is to advance the technology in VTK by providing direction and oversight to the development of VTK. While the open-source nature of VTK allows natural progression via its many developers, the ARB seeks to balance the intentions of each small group of developers, ensuring that changes will benefit the community as a whole. The ARB serves the following functions:<br />
* Maintain a roadmap of VTK including long-term plans.<br />
* Make decisions on high-impact code changes to VTK.<br />
<br />
==Scope of ARB Intervention==<br />
<br />
Code changes with a high impact on developers and/or users should be reviewed by the ARB. The following are some guiding principles for deciding whether changes require ARB involvement:<br />
* Will the change significantly affect backwards compatibility?<br />
* Does the change cause a significant shift in the functionality and scope of VTK?<br />
* Are there licensing issues with the code?<br />
Smaller feature additions and bug fixes will not in general require ARB approval, although they should in most cases have an associated development plan (see the [[VTK/Managing the Development Process|Managing the Development Process]] document).<br />
<br />
==Roles==<br />
<br />
The '''President''' organizes the meeting agenda and maintains the roadmap and the list of outstanding proposals requiring ARB intervention. He or she is also responsible for setting up ARB meeting times/places and ensuring that the goals of the meeting are accomplished. The president may invite individuals or groups who have submitted proposals to present their plans at ARB meetings.<br />
<br />
The '''Secretary''' keeps records of each meeting, assists in the setup of the meeting location and technology (e.g. projectors, video conferencing, etc.) required, and facilitates communication of proposals to the ARB, as well as decisions from the ARB back to the community.<br />
<br />
==Meetings==<br />
<br />
The ARB will meet on a schedule of their choosing and convenience, but at least once a quarter. The ARB may meet informally at any time as the need arises to evaluate proposals. ([[VTK/ARB/Meetings|Meeting notes and scheduled meetings are listed here]].)<br />
<br />
==Conflict Resolution==<br />
<br />
Conflicts will be resolved by discussion and consensus where at all possible. When such an agreement is impossible, the members of the ARB will vote on the issue, with the President breaking any tie vote.<br />
<br />
==Membership==<br />
<br />
Membership, while initially determined by Kitware, will develop organically from the ARB itself. ARB members are responsible for nominating new members, who are elected by consensus or majority vote (with the president breaking any tie). Existing members may step down from the ARB at any point. Members who are unable to attend meetings after reasonable effort to contact them, or are found to be exceedingly counterproductive to the purposes of the ARB, may be dropped from the ARB by consensus or vote.<br />
<br />
==Current Members==<br />
<br />
The following are the current members of the ARB. It is likely that many of these positions may change over time. The list below summarizes each members organization and expertise.<br />
<br />
* Jim Ahrens, Los Alamos National Laboratories (Supercomputing: VTK, ParaView)<br />
* Berk Geveci, Kitware Inc. (Supercomputing: VTK, ParaView)<br />
* Bill Lorensen, Master and Commander (Medical Imaging: VTK, Slicer)<br />
* Andrew Maclean, Centre for Autonomous Systems, University of Sydney (Geometry: VTK, Robotics, Software Process)<br />
* Steve Pieper, Isomics (Medical Imaging: VTK, Slicer)<br />
* Paolo Quadrani, CINECA System and Technology Department (Medical Imaging: VTK, MAF)<br />
* Will Schroeder, Kitware Inc. (Geometry, Data Structures, Algorithms: VTK)<br />
* Claudio Silva, University of Utah (Computational Sciences: VisTrails)<br />
* Brian Wylie, Sandia National Laboratories (This is a rotating position with other lead VTK technologists from Sandia) (Informatics: VTK, Titan)<br />
* Stephane Ploix, EDF (Supercomputing: VTK, ParaView, shared-memory parallelism)<br />
<br />
==Mailing List==<br />
This members only mailing list can be found at http://www.vtk.org/mailman/listinfo/arb</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=33075VTK/Marks2010-10-22T18:48:30Z<p>Jeff: </p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
[[VTK/Marks/Design]] describes some API design considerations.<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function instances. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
The source code is currently available as part of the [http://titan.sandia.gov Titan Toolkit] under the Libraries/Marks subdirectory, and it is slated to be moved into VTK in late 2010 or early 2011. Examples may be found in the tests under Libraries/Marks/Testing/Cxx.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
// Sizing and scales.<br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The root panel.<br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The bars.<br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The value label.<br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The variable label.<br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, "ABCDEFGHIJK", _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// X-axis ticks.<br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|<br />
<source lang="cpp"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks/Design&diff=33074VTK/Marks/Design2010-10-22T18:46:44Z<p>Jeff: Created page with "The following are some discussions about the design of the VTK/Marks classes. == Fleshing Out the vtkMark API == The fundamental type would be vtkMark, the superclass of all..."</p>
<hr />
<div>The following are some discussions about the design of the [[VTK/Marks]] classes.<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=33073VTK/Marks2010-10-22T18:44:06Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function instances. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
The source code is currently available as part of the [http://titan.sandia.gov Titan Toolkit] under the Libraries/Marks subdirectory, and it is slated to be moved into VTK in late 2010 or early 2011. Examples may be found in the tests under Libraries/Marks/Testing/Cxx.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
// Sizing and scales.<br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The root panel.<br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The bars.<br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The value label.<br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The variable label.<br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, "ABCDEFGHIJK", _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// X-axis ticks.<br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|<br />
<source lang="cpp"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/October_2010&diff=31378VTK/ARB/Meetings/October 20102010-10-06T16:20:55Z<p>Jeff: /* Meeting Notes */</p>
<hr />
<div>== Agenda ==<br />
* Stephane: [[VTK/MultiThreading]]<br />
* Stephane: [[Task Stealing framework]]<br />
* Bill: Sharing VTK contributions<br />
<br />
== Meeting Notes ==<br />
* We want to address potential incompatibilities with different implementations of multi-threading in VTK.<br />
* Pieper: ITK pipeline work with Intel, put pieces into separate processing units. Worked well, but with fairly shallow pipelines.<br />
* DeMarle: Streaming work does not do multithreading but could easily take advantage of it.<br />
* Schroeder: Older medical image streaming/multithreading in VTK where it is easy to break up the data. Intrafilter functionality along with streaming among filters to have smaller memory footprint.<br />
* Need more separation between process objects and execution model. Need to preserve simple path for programmers for writing new algorithms.<br />
* Stephane: Task stealing can work intra-algorithm and inter-algorithm. First step is to have it work intra-algorithm. Task stealing should be complementary to HyperFlow. One use case is improving contouring algorithm or other non-parallel algorithm.<br />
* Want to support unstructured and structured data structures.<br />
* Want to build a library that makes it easy to iterate over VTK data structures in ways that would be useful to several algorithms.<br />
* Need to test speed, memory consumption of new filters.<br />
* Need to clean up API for VTK data objects to be thread-safe.<br />
* Suggest that we start with simple example of parallelizing the filter, perhaps streamlines, contours.<br />
* HyperFlow and task stealing may have to communicate in order to not overallocate resources?<br />
** Task stealing only uses threads that are not busy so this may not be an issue.<br />
* KAAPI<br />
** Has no central resource allocation.<br />
** It is LGPL with potential to change it.<br />
** No Windows support yet.<br />
** 22K lines of code.<br />
** Has GPU support.<br />
* Need a set of pipeline use cases that can be tested.<br />
* First integration next year, on a branch of VTK.<br />
* Bill - Way for external people to access submitted features. Talk to Steve about how ITK does extensions.<br />
** "Modules" for Insight Journal. Code automatically goes into Git repository.<br />
** Boolean operations for VTK is a good example of code that will likely not go into VTK but is useful.<br />
** Need to be able to scale the community.<br />
<br />
== Action Items ==<br />
* Send any additional multi-threading use cases to Stephane.<br />
* Coordinate on setting up "modules" for VTK Journal (Bill and Will).<br />
<br />
== Next Time ==<br />
* More on sharing code contributions.<br />
* VTK library reorganization.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/October_2010&diff=31377VTK/ARB/Meetings/October 20102010-10-06T16:18:04Z<p>Jeff: Created page with "== Agenda == * Stephane: VTK/MultiThreading * Stephane: Task Stealing framework * Bill: Sharing VTK contributions == Meeting Notes == * We want to address potential inco..."</p>
<hr />
<div>== Agenda ==<br />
* Stephane: [[VTK/MultiThreading]]<br />
* Stephane: [[Task Stealing framework]]<br />
* Bill: Sharing VTK contributions<br />
<br />
== Meeting Notes ==<br />
* We want to address potential incompatibilities with different implementations of multi-threading in VTK.<br />
* Pieper: ITK pipeline work with Intel, put pieces into separate processing units. Worked well, but with fairly shallow pipelines.<br />
* DeMarle: Streaming work does not do multithreading but could easily take advantage of it.<br />
* Schroeder: Older medical image streaming/multithreading in VTK where it is easy to break up the data. Intrafilter functionality along with streaming among filters to have smaller memory footprint.<br />
* Need more separation between process objects and execution model. Need to preserve simple path for programmers for writing new algorithms.<br />
* Stephane: Task stealing can work intra-algorithm and inter-algorithm. First step is to have it work intra-algorithm. Task stealing should be complementary to HyperFlow. One use case is improving contouring algorithm or other non-parallel algorithm.<br />
* Want to support unstructured and structured data structures.<br />
* Want to build a library that makes it easy to iterate over VTK data structures in ways that would be useful to several algorithms.<br />
* Need to test speed, memory consumption of new filters.<br />
* Need to clean up API for VTK data objects to be thread-safe.<br />
* Suggest that we start with simple example of parallelizing the filter, perhaps streamlines, contours.<br />
* HyperFlow and task stealing may have to communicate in order to not overallocate resources?<br />
** Task stealing only uses threads that are not busy so this may not be an issue.<br />
* KAAPI<br />
** Has no central resource allocation.<br />
** It is LGPL with potential to change it.<br />
** No Windows support yet.<br />
** 22K lines of code.<br />
** Has GPU support.<br />
* Need a set of pipeline use cases that can be tested.<br />
* First integration next year, on a branch of VTK.<br />
* Bill - Way for external people to access submitted features. Talk to Steve about how ITK does extensions.<br />
** "Modules" for Insight Journal. Code automatically goes into Git repository.<br />
** Boolean operations for VTK is a good example.<br />
** Need to be able to scale the community.<br />
** Talk more on this next time.</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=31376VTK/ARB/Meetings2010-10-06T16:15:28Z<p>Jeff: /* Past Meetings */</p>
<hr />
<div>== Scheduled Meetings ==<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/October 2010|October 6, 2010]]<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28762VTK/ARB/Meetings/August 20102010-08-17T20:43:06Z<p>Jeff: /* Notes */</p>
<hr />
<div>== Agenda ==<br />
* http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility<br />
* http://www.vtk.org/Wiki/VTK/Modularization_Proposal<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* Only incompatibility is that people need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
** This is not much of an issue since VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* Look at what ITK does with [http://ryppl.org Ryppl] this coming year<br />
* Possibly use namespaces?<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* '''Consensus: This will be a good thing, let's do it.'''<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Should communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.'''<br />
<br />
== Action Items ==<br />
* (Berk) Send information about XML C interface to ARB<br />
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community<br />
* (Berk) Look into defining some variables that make old targets work<br />
* (Kitware and VTK community) Do modularization of kits<br />
* (Kitware) Remove 4.0 legacy code<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28761VTK/ARB/Meetings/August 20102010-08-17T20:41:29Z<p>Jeff: /* Notes */</p>
<hr />
<div>== Agenda ==<br />
* http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility<br />
* http://www.vtk.org/Wiki/VTK/Modularization_Proposal<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* People need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
** This is not much of an issue since VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* Look at what ITK does with [http://ryppl.org Ryppl] this coming year<br />
* Possibly use namespaces?<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* '''Consensus: This will be a good thing, let's do it.'''<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Should communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.'''<br />
<br />
== Action Items ==<br />
* (Berk) Send information about XML C interface to ARB<br />
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community<br />
* (Berk) Look into defining some variables that make old targets work<br />
* (Kitware and VTK community) Do modularization of kits<br />
* (Kitware) Remove 4.0 legacy code<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=28760VTK/ARB/Meetings2010-08-17T20:39:42Z<p>Jeff: </p>
<hr />
<div>== Scheduled Meetings ==<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=28759VTK/ARB/Meetings2010-08-17T20:39:24Z<p>Jeff: </p>
<hr />
<div>== Scheduled Meetings ==<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==<br />
* Multi-threading strategy (Stephane PLOIX)<br />
* I'd like to discuss starting to remove the backwards compatibility layer we implemented to transition from VTK 4 to 5. It has been a long time since 5.0 and it is time. The backwards compatibility layer has a lot code that is preventing us to clean up the pipeline logic in VTK. The main one being the use of vtkDataObject to carry meta-data during pipeline passes. (Berk Geveci)</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28757VTK/ARB/Meetings/August 20102010-08-17T20:37:44Z<p>Jeff: /* Action Items */</p>
<hr />
<div>== Agenda ==<br />
* http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility<br />
* http://www.vtk.org/Wiki/VTK/Modularization_Proposal<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* People need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
** This is not much of an issue since VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* Look at what ITK does with Rippl this coming year<br />
* Possibly use namespaces?<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* '''Consensus: This will be a good thing, let's do it.'''<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Should communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.'''<br />
<br />
== Action Items ==<br />
* (Berk) Send information about XML C interface to ARB<br />
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community<br />
* (Berk) Look into defining some variables that make old targets work<br />
* (Kitware and VTK community) Do modularization of kits<br />
* (Kitware) Remove 4.0 legacy code<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28756VTK/ARB/Meetings/August 20102010-08-17T20:37:11Z<p>Jeff: /* Agenda */</p>
<hr />
<div>== Agenda ==<br />
* http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility<br />
* http://www.vtk.org/Wiki/VTK/Modularization_Proposal<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* People need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
** This is not much of an issue since VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* Look at what ITK does with Rippl this coming year<br />
* Possibly use namespaces?<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* '''Consensus: This will be a good thing, let's do it.'''<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Should communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.'''<br />
<br />
== Action Items ==<br />
* (Berk) Send information about XML C interface to ARB<br />
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community<br />
* (Berk) Look into defining some variables that make old targets work<br />
* (Kitware) Do modularization of kits<br />
* (Kitware) Remove 4.0 legacy code<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28755VTK/ARB/Meetings/August 20102010-08-17T20:36:48Z<p>Jeff: </p>
<hr />
<div>== Agenda ==<br />
http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility<br />
http://www.vtk.org/Wiki/VTK/Modularization_Proposal<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* People need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
** This is not much of an issue since VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* Look at what ITK does with Rippl this coming year<br />
* Possibly use namespaces?<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* '''Consensus: This will be a good thing, let's do it.'''<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Should communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.'''<br />
<br />
== Action Items ==<br />
* (Berk) Send information about XML C interface to ARB<br />
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community<br />
* (Berk) Look into defining some variables that make old targets work<br />
* (Kitware) Do modularization of kits<br />
* (Kitware) Remove 4.0 legacy code<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28753VTK/ARB/Meetings/August 20102010-08-17T20:15:56Z<p>Jeff: </p>
<hr />
<div>== Agenda ==<br />
<br />
== Notes ==<br />
Modularization<br />
* Reorganize VTK, clean up dependencies<br />
* Clean up build process, use newer CMake functionality<br />
* Copy out some subdirectories into separate repository<br />
* People need to link to a different set of libraries<br />
* Kit boundaries are bound by subclasses<br />
* VTK has a "fat" hierarchy tree<br />
* Within common, there are things that are not too common<br />
** Implicit functions, math, etc.<br />
* Make a graph of dependencies, perhaps do clustering<br />
* What dependencies do the examples have?<br />
* Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK<br />
* (Berk) Send information about XML C interface<br />
* Look at what ITK does with Rippl this coming year<br />
* Possibly use namespaces?<br />
* (Berk) Ask for help from topic experts on how to organize the classes<br />
* Move some informatics stuff into Titan as part of the reorganization<br />
* Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs<br />
* Remove unnecessary dependencies among kits<br />
* (Berk) Define some variables that make old targets work?<br />
<br />
Removing 4.0 compatibility layer<br />
* In VTK 4.0, left interdependencies between data objects and pipeline<br />
* Main incompatibility is people using b->SetInput(a->GetOutput())<br />
* Should we leave the SetInput() function?<br />
** Leaving it will produce a runtime error for the case above. It would also allow existing code to work.<br />
** Changing the name to SetInputDataObject() will produce a compile-time error.<br />
* Make a script that checks for these errors.<br />
* Flagging errors in next release when people are connecting pipelines using SetInput()<br />
* Communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.<br />
* Make sure "key" toolkits are ready and notified of upcoming changes<br />
** Slicer<br />
** ITK<br />
** ParaView<br />
** VisTrails<br />
** Titan<br />
** others?<br />
<br />
== Action Items ==<br />
<br />
== Some Other Time ==<br />
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/August_2010&diff=28751VTK/ARB/Meetings/August 20102010-08-17T18:57:36Z<p>Jeff: Created page with '== Agenda == == Notes == == Action Items =='</p>
<hr />
<div>== Agenda ==<br />
<br />
== Notes ==<br />
<br />
== Action Items ==</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings&diff=28750VTK/ARB/Meetings2010-08-17T18:56:28Z<p>Jeff: </p>
<hr />
<div>== Scheduled Meetings ==<br />
* [[VTK/ARB/Meetings/August 2010|August 17, 2010]]<br />
<br />
== Past Meetings ==<br />
* [[VTK/ARB/Meetings/July 2010|July 13, 2010]]<br />
* [[VTK/ARB/Meetings/April 2010|April 1, 2010]]<br />
* [[VTK/ARB/Meetings/January 2010|January 13, 2010]]<br />
* [[VTK/ARB/Meetings/November 2009|November 3, 2009]]<br />
* [[VTK/ARB/Meetings/October 2009|October 1, 2009]]<br />
<br />
== Potential Topics ==<br />
* Multi-threading strategy (Stephane PLOIX)<br />
* I'd like to discuss starting to remove the backwards compatibility layer we implemented to transition from VTK 4 to 5. It has been a long time since 5.0 and it is time. The backwards compatibility layer has a lot code that is preventing us to clean up the pipeline logic in VTK. The main one being the use of vtkDataObject to carry meta-data during pipeline passes. (Berk Geveci)</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26697VTK/Marks2010-08-06T20:01:45Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function instances. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
// Sizing and scales.<br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The root panel.<br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The bars.<br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The value label.<br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The variable label.<br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, "ABCDEFGHIJK", _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// X-axis ticks.<br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|<br />
<source lang="cpp"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26696VTK/Marks2010-08-06T19:56:37Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function instances. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
// Sizing and scales.<br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The root panel.<br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The bars.<br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The value label.<br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The variable label.<br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, vtkStdString("ABCDEFGHIJK"), _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// X-axis ticks.<br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|<br />
<source lang="cpp"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26695VTK/Marks2010-08-06T19:53:20Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function objects. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
// Sizing and scales.<br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The root panel.<br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The bars.<br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The value label.<br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
// The variable label.<br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, vtkStdString("ABCDEFGHIJK"), _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
// X-axis ticks.<br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|<br />
<source lang="cpp"><br />
// Render the scene.<br />
vis.render();<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26694VTK/Marks2010-08-06T19:48:25Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
The purpose of this prototype was to see how closely C++ code can resemble Protovis Javascript code. The properties are defined as boost::function objects. boost::lambda expressions (lines using the special _index and _d variables) may be used to specify functions. Alternately, free/static functions or function objects may be used. The bottom images show the results from both pieces of code.<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, vtkStdString("ABCDEFGHIJK"), _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=File:MarksBarChart.png&diff=26693File:MarksBarChart.png2010-08-06T19:41:26Z<p>Jeff: </p>
<hr />
<div></div>Jeffhttps://public.kitware.com/Wiki/index.php?title=File:ProtovisBarChart.png&diff=26692File:ProtovisBarChart.png2010-08-06T19:41:06Z<p>Jeff: </p>
<hr />
<div></div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26691VTK/Marks2010-08-06T19:39:00Z<p>Jeff: /* Initial Prototype */</p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
var data = pv.range(10).map(function(d) { return Math.random() + .1; });<br />
</source><br />
|<br />
<source lang="cpp"><br />
std::vector<double> vec;<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
vec.push_back(vtkMath::Random() + 0.1);<br />
}<br />
VectorStorage* s = new VectorStorage(vec);<br />
Datum data(s);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// Sizing and scales.<br />
var w = 400,<br />
h = 250,<br />
x = pv.Scale.linear(0, 1.1).range(0, w),<br />
y = pv.Scale.ordinal(pv.range(10)).splitBanded(0, h, 4/5);</source><br />
|<br />
<source lang="cpp"><br />
int w = 400;<br />
int h = 250;<br />
LinearScale x(0, 1.1);<br />
x.range(0, w);<br />
OrdinalScale y(range(10));<br />
y.splitBanded(0, h, 4.0/5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The root panel.<br />
var vis = new pv.Panel()<br />
.width(w)<br />
.height(h)<br />
.bottom(20)<br />
.left(20)<br />
.right(10)<br />
.top(5);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Panel vis;<br />
vis.width(w);<br />
vis.height(h);<br />
vis.bottom(20);<br />
vis.left(20);<br />
vis.right(10);<br />
vis.top(5);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The bars.<br />
var bar = vis.add(pv.Bar)<br />
.data(data)<br />
.top(function() y(this.index))<br />
.height(y.range().band)<br />
.left(0)<br />
.width(x);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Bar* bar = vis.addBar();<br />
bar->data(data);<br />
bar->top(bind(y, _index));<br />
bar->height(y.band());<br />
bar->left(0);<br />
bar->width(x);<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The value label.<br />
bar.anchor("right").add(pv.Label)<br />
.textStyle("white")<br />
.text(function(d) d.toFixed(1));<br />
</source><br />
|<br />
<source lang="cpp"><br />
Label* label = bar->anchor("right")->addLabel();<br />
label->textStyle(vtkColor4d(1, 1, 1, 1));<br />
label->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// The variable label.<br />
bar.anchor("left").add(pv.Label)<br />
.textMargin(5)<br />
.textAlign("right")<br />
.text(function() "ABCDEFGHIJK".charAt(this.index));<br />
</source><br />
|<br />
<source lang="cpp"><br />
Label* label2 = bar->anchor("left")->addLabel();<br />
label2->textMargin(5);<br />
label2->textAlign(vtkStdString("right"));<br />
label2->text(bind(charAt, vtkStdString("ABCDEFGHIJK"), _index));<br />
</source><br />
|-<br />
|<br />
<source lang="javascript"><br />
// X-axis ticks.<br />
vis.add(pv.Rule)<br />
.data(x.ticks(5))<br />
.left(x)<br />
.strokeStyle(function(d) d ? "rgba(255,255,255,.3)" : "#000")<br />
.add(pv.Rule)<br />
.bottom(0)<br />
.height(5)<br />
.strokeStyle("#000")<br />
.anchor("bottom").add(pv.Label)<br />
.text(x.tickFormat);<br />
</source><br />
|<br />
<source lang="cpp"><br />
Rule* rule = vis.addRule();<br />
rule->data(x.ticks(5));<br />
rule->left(x);<br />
rule->strokeStyle(if_then_else_return(_d[0] > 0, vtkColor4d(1, 1, 1, 0.3), vtkColor4d(0, 0, 0, 1)));<br />
<br />
Rule* rule2 = rule->addRule();<br />
rule2->bottom(0);<br />
rule2->height(5);<br />
rule2->strokeStyle(vtkColor4d(0, 0, 0, 1));<br />
<br />
Label* l = rule2->anchor("bottom")->addLabel();<br />
l->text(bind(toFixed, _d, 1));<br />
</source><br />
|-<br />
| [[Image:ProtovisBarChart.png]]<br />
| [[Image:MarksBarChart.png]]<br />
|-<br />
|}<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/Marks&diff=26690VTK/Marks2010-08-06T19:22:52Z<p>Jeff: </p>
<hr />
<div>== Overview ==<br />
Marks can be thought of as highly-configurable vectorized graphics items, or graphics item factories. They are a mid-level API built on more basic rendering primitives like lines, circles, etc. You want to use marks to make it easy to configure a set of primitives, where each primitive's properties will change depending on the item.<br />
<br />
[http://www.protovis.org Protovis] is an API description for marks with a reference implementation in javascript. Take a look at the protovis site for details on their design decisions and features.<br />
<br />
In VTK, we want to explore a similar interface for marks in C++. The following is a possible technology stack for using marks in VTK. Qt could be incorporated as an alternative to OpenGL for publication-quality images.<br />
<br />
[[Image:Marks.png]]<br />
<br />
== Initial Prototype ==<br />
<br />
{| border="1"<br />
! Protovis<br />
! C++<br />
|-<br />
|<br />
<source lang="javascript"><br />
</source><br />
|<br />
<source lang="cpp"><br />
</source><br />
|-<br />
|}<br />
<br />
[[Image:ProtovisBarChart.png]]<br />
<br />
[[Image:MarksBarChart.png]]<br />
<br />
== Fleshing Out the vtkMark API ==<br />
The fundamental type would be vtkMark, the superclass of all mark types. Its interface would define how programmers would work with all marks in VTK. The following sections enumerate some possible use cases with code snippets showing what functionality the feature would allow.<br />
<br />
=== Possible Supported Parameter Types ===<br />
<br />
{| border="1"<br />
! Description<br />
! Example Code<br />
|-<br />
| Basic types (double, int, string, vtkVariant)<br />
| <source lang="cpp"><br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", 10);<br />
</source><br />
|-<br />
| Data object<br />
| <source lang="cpp"><br />
vtkDirectedGraph* g = vtkDirectedGraph::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", g);<br />
</source><br />
|-<br />
| Pipeline output port<br />
| <source lang="cpp"><br />
vtkRandomGraphSource* s = vtkRandomGraphSource::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("data", s->GetOutputPort());<br />
</source><br />
|-<br />
| vtkArray<br />
| <source lang="cpp"><br />
vtkDenseArray<double>* a = vtkDenseArray<double>::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| vtkAbstractArray<br />
| <source lang="cpp"><br />
vtkDoubleArray* a = vtkDoubleArray::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", a);<br />
</source><br />
|-<br />
| Data object + field type + array name<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", t, vtkDataObject::ROW, "columnName");<br />
</source><br />
|-<br />
| Data object + field type + array name + component index<br />
| <source lang="cpp"><br />
vtkTable* t = vtkTable::New();<br />
vtkDoubleArray* loc = vtkDoubleArray::New();<br />
loc->SetNumberOfComponents(2);<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("left", t, vtkDataObject::ROW, "location", 0);<br />
m->SetParameter("bottom", t, vtkDataObject::ROW, "location", 1);<br />
</source><br />
|-<br />
| Function pointer<br />
| <source lang="cpp"><br />
double MySize(vtkMark* m, int i) { return 10*i; }<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", &MySize);<br />
</source><br />
|-<br />
| Functor (i.e. struct type with operator()) - requires SetParameter to be templated.<br />
| <source lang="cpp"><br />
struct MySize {<br />
double operator()(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Lambda function (boost::lambda)<br />
|<br />
|-<br />
| Parameter strategies<br />
| <source lang="cpp"><br />
class vtkDoubleParameter {<br />
virtual double Get(vtkMark* m, int i) = 0;<br />
}<br />
<br />
class MySize : public vtkDoubleParameter {<br />
protected:<br />
double Get(vtkMark* m, int i) { return 10*i; }<br />
}<br />
//...<br />
vtkDotMark* m = vtkDotMark::New();<br />
m->SetParameter("size", MySize());<br />
</source><br />
|-<br />
| Override virtual methods in mark<br />
| <source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
virtual double GetSize(int i) { return 10; }<br />
}<br />
<br />
class MyMark : public vtkDotMark {<br />
protected:<br />
double GetSize(int i) { return 10*i; }<br />
}<br />
//...<br />
MyMark* m = MyMark::New();<br />
</source><br />
|-<br />
| Inherit from parent mark<br />
| <source lang="cpp"><br />
vtkDotMark* parent = vtkDotMark::New();<br />
parent->SetParameter("size", 10);<br />
vtkDotMark* child = vtkDotMark::New();<br />
parent->Add(child); // Child has size 10<br />
</source><br />
|}<br />
<br />
<br />
=== Possible Parameter Storage and Access ===<br />
<br />
==== Named member variables ====<br />
<source lang="cpp"><br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Named member variables with import/export to name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ this->ExportSettings()->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->ImportSettings(this->ExportSettings()->SetParameter(key, p)); }<br />
virtual void ImportSettings(vtkSettings* s) { }<br />
virtual vtkSettings* ExportSettings() { return vtkSettings::New(); }<br />
}<br />
<br />
class vtkDotMark {<br />
public:<br />
ParamType GetSize() { return this->Size; }<br />
void SetSize(ParamType p) { this->Size = p; }<br />
virtual vtkSettings* ExportSettings()<br />
{ return this->Parent->ExportSettings()->SetParameter("size", this->Size); }<br />
virutal void ImportSettings(vtkSettings* s)<br />
{ this->Size = s->GetParameter("size"); }<br />
private:<br />
ParamType Size;<br />
}<br />
</source><br />
<br />
==== Generic name/value map ====<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
ParamType GetParameter(string key)<br />
{ return this->Parameters[key].Valid ? this->Parameters[key] : this->Parent->GetParameter(key); }<br />
void SetParameter(string key, ParamType p)<br />
{ this->Parameters[key] = p; }<br />
private:<br />
map<string, ParamType> Parameters;<br />
}<br />
</source><br />
<br />
==== Generic name/value map with setter/getter syntactic sugar for discoverability ====<br />
<source lang="cpp"><br />
class vtkDotMark : public vtkMark {<br />
public:<br />
ParamType GetSize() { return this->GetParameter("size"); }<br />
void SetSize(ParamType p) { this->SetParameter("size", p); }<br />
}<br />
</source><br />
<br />
==== vtkInformation/value map ====<br />
The idea here is that valid parameter names/types/bounds are queryable at runtime, instead of in an opaque map.<br />
<source lang="cpp"><br />
class vtkMark {<br />
public:<br />
// Keys to describe parameters<br />
static vtkInformationIntegerKey* PARAMETER_TYPE();<br />
static vtkInformationStringKey* PARAMETER_NAME();<br />
static vtkInformationIntegerKey* PARAMETER_NUMBER_OF_COMPONENTS();<br />
static vtkInformationIntegerVectorKey* PARAMETER_INTEGER_BOUNDS();<br />
static vtkInformationDoubleVectorKey* PARAMETER_REAL_BOUNDS();<br />
<br />
int GetNumberOfParameters() { return this->ParameterInfo->size(); }<br />
vtkInformation* GetParameterInfo(int i) { return this->ParameterInfo[i]; }<br />
int GetParameterHandle(const char* name)<br />
{ /* search ParameterInfo for name, return index */ }<br />
void SetParameter(int handle, ParamType p)<br />
{ this->ParameterValues[handle] = p; }<br />
<br />
protected:<br />
virtual void SetupParameters() = 0;<br />
vector<vtkInformation*> ParameterInfo;<br />
vector<ParamType> ParameterValues;<br />
}<br />
<br />
class vtkDotMark : public vtkMark {<br />
protected:<br />
void SetupParameters()<br />
{<br />
vtkInformation* sizeInfo = vtkInformation::New();<br />
double sizeBounds[2] = { 0., VTK_DOUBLE_MAX };<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NAME(), "size" );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_TYPE(), VTK_DOUBLE );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_NUMBER_OF_COMPONENTS(), 1 );<br />
sizeInfo->Set( vtkPointMark::PARAMETER_REAL_BOUNDS(), sizeBounds, 2 );<br />
this->ParameterInfo.push_back(sizeInfo);<br />
this->ParameterValues.push_back(10);<br />
}<br />
}<br />
</source><br />
<br />
=== Possible Other Features ===<br />
<br />
* Declarative API<br />
* Iterator support</div>Jeffhttps://public.kitware.com/Wiki/index.php?title=VTK/ARB/Meetings/July_2010&diff=25040VTK/ARB/Meetings/July 20102010-07-13T14:49:27Z<p>Jeff: /* Notes */</p>
<hr />
<div>==Agenda==<br />
<br />
* Berk: Move to git - New workflow discussion<br />
* Berk: VTK 6.0 timing<br />
* Berk/Jeff: Wrapping changes<br />
** Integration with ITK wrapping?<br />
* All: Library reorganization<br />
** Should we work on modularization, glue code to other toolkits?<br />
* Bill: [[VTK/Examples|Wiki Examples]] update<br />
* Stephane: Multi-core, hybrid working group<br />
* Brian: Introspection support<br />
<br />
==Notes==<br />
<br />
* Berk: Move to git - New workflow discussion<br />
** Relatively smooth transition<br />
** Have been doing a linear history with rebase, but moving to branchy workflow<br />
** Multiple integration branches (master and next)<br />
** next - like previous CVS head, not as stable, development happens here<br />
** master - always stable, only merge tested changes, tag master to do release<br />
** Goal is for both next and master green<br />
** Will need to be some education about topic branches<br />
** Staging repository for VTK coming online<br />
** Need to make sure things don't linger in next<br />
** Make staging a requirement? Would like this in the future<br />
** Dashboard for topic branches? Not the hardware resources<br />
** Have tutorials on Git at conferences<br />
* Berk: VTK 6.0 timing<br />
** Next release will be Sept-Oct, may or may not be 6.0<br />
** Synchronizing VTK/ParaView releases on 6-month release cycle<br />
* Berk/Jeff: Wrapping changes<br />
** Perhaps add contract-based documentation that would exclude some set/get from testing<br />
** Integration with ITK wrapping?<br />
* All: Library reorganization<br />
** Allow people to extract smaller subsets of VTK to use in their projects<br />
** Look into Qt PRL<br />
** Maybe look at separating into separate Git repositories, superbuild of VTK<br />
** Should we work on modularization, glue code to other toolkits?<br />
* Bill: [[VTK/Examples|Wiki Examples]] update<br />
** Automatically scrapes the wiki to get example code and test with a Gitorious repository<br />
* Stephane: Multi-core, hybrid working group<br />
** Claudio has worked on parallel pipeline<br />
** There are other ways that are not compatible with this<br />
** Aims to have no conflicts between each other, collaborate if possible, could be brought to the ARB when decisions need to be made<br />
** Have discussion in ARB on high level strategy and then open to vtk-developers / wiki / etc.<br />
** Possibly have a shared topic branch or repo for this type of work<br />
** Work on setting goals at a special ARB meeting<br />
* Meet more frequently, have next meeting in 1 month<br />
<br />
==Action Items==<br />
* Stephane - Set up wiki page for sharing thoughts on multi-core architecture in VTK<br />
* Bill - Announce new features of VTK examples to VTK list and organize writing a VTK Journal / Source article<br />
* Will - Talk to ITK guys about what's going on with wrapping<br />
* Berk - Organize/clean Git wiki pages and send pointers ARB/VTK lists<br />
<br />
==Next Time==<br />
* Have an ARB summit? Meet at conference a day early?<br />
* Special meeting for multi-core discussion<br />
* Berk - VTK release and backward compatibility<br />
* Brian - Introspection support</div>Jeff