from a visualization framework to a visual programming environment

1
from avisualization framework to avisual
programming environment

• santiago v lombeyda
• michael aivazis
• matt gilbert

2
isolating the visual framework

• by visual framework we define a
• a visual interface (i.e. boxes and lines in
  Viper)
• used to control the setup and/or execution of
  several interconnected or interdependent actions
  or modules
• where
• semantics and actual execution are controlled
  outside the visual framework
• the visual framework itself is not task specific

3
growing beyond current paradigms

• mostly task specific/focused
• most purely developed for visualization
• examples OpenDX, IRIS Explorer, AVS, Viper
• tradeoff between stability and flexibility
• do not age well
• are mostly extremely dependent on their function
  and internal data structures
• do not allow for new execution paradigms
• part large packages
• hard to port and share

4
as a visual elements layerin context example
display technologies
T221/PICA
visual framework
VPE
remote control
gViz
simulation control
Viper/Pyre
VTF
executable modules
5
enabling solutions for new needs

• more intuitive ways of understanding
• how large simulations are put together
• how large simulations are performing
• debugging
• how data are being shared
• how to better convey information to new users
• need more simplicity and more flexibility
• needs to be portable
• needs to be detached from the executing code
• needs to allow for new visual paradigms
• needs to be able to share it

6
generalizing to visual programming environments

• more intuitive ways to
• link work modules together
• ways to process data
• ways to set up simulations
• ways to set up, monitor, and steer complicated,
  large, long running, remote batch jobs
• focusing on not to re-invent the wheel

7
moduleinterface
visual mockups
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
resulting in current work

• defining and implementing an API
• GL based alone
• event callback GTK inspired
• object definition OpenInventor inspired
• basic visual widget set JavaAWT inspired
• flexible visual appearance
• defined as variable image composition (skins)
• draw as GL images with depth associated
• support transparency!

18
current api structure
19
vpe api

• object oriented
• widgets are sample objects rather than base atoms
  for interaction
• callbacks and rendering (gl) can be overriden or
  extended
• event hooks come in from GLUT, GTK, etc
• but not GLUT nor X dependent
• basic events needed must be passed to vpeRoot
• currently researching text rendering (freetype?
  pango?)

20
vtf monitor as a prototype

• basic tools for fast prototyping
• style options
• predetermined
• GIMP/Photoshop images and masks
• gui creation
• blade
• an xml glade
• direct use of api

21
summary

• goal
• isolate visual layer, in order to enable new
  paradigms and better interaction
• offer clear view of systems state
• allow precise and efficient control
• offering a true sense of ownership

22
visualization frameworks

• santiago v lombeyda
• michael aivazis

CALIFORNIA INSTITUTE OF TECHNOLOGY