VAPORGUI Code Refactoring

Issues

1. How to achieve largely user-invisible code refactoring while providing improvements as well.

Goals

Extensibility: Facilitate addition of new features by VAPOR and 3rd party developers. Specific examples:

• New importers of foreign data into the DataMgr (high priority)
• New (or enhanced) renderers and associated GUI control
• New data grids

Limitations: Several limitations in the current implementation exist that need to be addressed to support future needs

• Single grid: vaporgui expects all data variables in a VDC to be sampled on a single grid
• Regular grid structure: The only grid type supported is a tesselation of 2D or 3D Euclidean space by rectangles or parallelpipeds
• Single data set: only a single VDC can be loaded at one time
• Spherical data: horizontal slices of spherical data must be projected to 2D before they can be operated on

maintainability: Facilitate code maintenance

• Definition of major components. E.g. what are they, what do they do, what do they not do, how do they interact with other components
• OpenGL state mgt: There is not centralized management of OpenGL state. It's very easy for state to become corrupted. Mixing of fixed function and programmable pipeline may be problematic. Code is based on pre-OpenGL3.0 api
• Elimination/reduction of task-level parallelism. It's not needed and unsafe
• Code cleanup: prune dead code, better document surviving code, etc.

Misc:

• Error handling improvements (e.g. too many popups)
• Rendering control: presently no way to control when a renderer is triggered

Two Year Plan - 2012