JavaOne and next steps for VisAD

This describes some events connected with JavaOne last week,
and future plans for VisAD development.
 
1. Java 3D and VisAD performance: Java 3D cannot run with native
threads or JITs, although Sun says they are working hard on
changing this.  On the other hand, VisAD is written to make very
few method calls (no method calls once per pixel or per gridpoint)
and the Sun engineers say that the new HotSpot compiler / intepreter
should do well with such code.  Thus we expect a big increase in
VisAD performance when Java 3D can be used with HotSpot, native
threads and JITs.
 
2. Platforms: Other companies (e.g., IBM and HP) are putting lots
of resources into Java including good compilers.  Technically, it
will be easy to port Java 3D to any platform with OpenGL, and
hopefully user demand will drive other vendors to want Java 3D.  I
believe a Macintosh port is in the works.  SGI is the big question
but the demand is so great that some solution will materialize.
 
3. GoesCollaboration example application: I had a nice talk with
YanChing Zhang of the U.S. EPA last week.  We identified a number
of areas where the GoesCollaboration source could be clearer, so
I cleaned that up this weekend.  Also, I implemented her suggestion
that applications have a way to set colors of axis scales (so, for
example, the termperature scale can be the same color as the
termperature graph).  Because GoesCollaboration is our promary
coding example of how to build complete VisAD applications, it is
important that it be clear.
 
4. Support for our collaborators and users: Now that Java 3D is
publically available and thus VisAD can be used, the highest
priority for all of us who have worked on VisAD must be supporting
collaborators and users who are just starting to work with VisAD.
 
This mailing list is the preferred way to let us know about
problems.  Answering these questions will take priority over
new developments.
 
Furthermore, we will use this mailing list for design discussions
in order to keep everyone informed and to broaden input into
design decisions.
 
5. Java 2D visualization support: I have been intending to provide
a visualization alternative based on Java 2D rather than Java 3D,
and my goal is to have this ready by the end of September.  Java 2D
is a core Java package (Java 3D is a core extension and so not
mandatory).  Furthermore, Java 2D may provide better performance on
systems without 3-D graphics hardware.
 
6. User interface tools: This is clearly the next big emphasis in
the development of VisAD.  Issues include:
 
  A. Support for 'cloning' a Display from one JVM (Java Virtual
     Machine) to another, including an option to link all
     ControlEvents between two or more 'cloned' Displays.  This
     will help suuport remote collaboration.  We have started
     working on this, and this is an immediate focus for us.
 
  B. Defining JavaBean components to support building VisAD
     applications as logical networks of Data objects, Display
     objects, user interface objects, and computational 'Cell'
     objects.  Important sub-issues include:
 
     1. Blurring the distinction between design time and run time
        so that users can dynamically reconfigure networks and
        make design choices in the middle of computations.  For
        example, a Display design component may provide menus of
        RealTypes and DispayRealTypes where users can define
        ScalarMaps by 'drawing' connections, but the RealTypes
        associated with Data objects may not be available until
        the Data objects have been computed (e.g., read from a
        netCDF file).
 
     2. How JavaBean components can be used to define logical
        networks of objects that span multiple JVMs.
 
     Sub-issues 1 and 2 seem like they would be of general concern
     and for all I know they may be addressed in the JavaBeans
     design.
 
     JavaBean components are a big topic and this may be an active
     area of collaboration between at least SSEC and Unidata.
 
  C. Developing a generic spread sheet user interface.  For example,
     each spread sheet cell could include one Display and one Data
     object, plus a Data source which could either be a file, a
     computational Cell (i.e., compute the Data objects from the
     Data in other cells), or direct manipulation (i.e., the user
     draws the Data values).  Clearly this may make use of JavaBean
     components.  We are planning to start work on this soon.
 
7. Data analysis tools: This is important for supporting
applications.  Examples include methods to transform the MathTypes
of Data, methods to resample Functions in particular ways,
statistical methods, Function derivatives and integrals, etc.
This could also include formula parsers and interpreters, possibly
even Java interpreters written in Java in order to support the
interactive programming window approach of the C implementation
of VisAD.  We will start work on this soon.
 
8. Fixing bugs and filling in UnimplementedExceptions: the good
news is that tracking down bugs is a snap in Java, even in a
system as complex as VisAD.  There are also a number of places
where code throws UnimplementedExceptions.
 
It has been great to be able to announce VisAD simultaneously
with Java 3D.  Now we need to focus on the next steps.
 
Bill
 
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI  53706
whibbard@xxxxxxxxxxxxx  608-263-4427  fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html

  • 1998 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: