RE: Java Graphics Speeds (was: Compare Swarm with Repast)

[Christopher J. Mackie]

If you want really fast Java graphics, substitute IBM's Standard Widget
Toolkit for Java's AWT and Swing.  You sacrifice some platform-compatibility
(not much), but you gain substantial (30% to order-of-magnitude, depending
on who's counting and counting what) performance improvements throughout.
IBM does it by breaking Sun's "no platform-specific UI tweaking" model,
which is why it's available for fewer platforms.  Need I say that Sun hates
it (but developers seem to love it)?

My guess is that a JavaSwarm or RePast model with SWT GUI would be the
cleanest test of the relative language (as opposed to GUI) performance, v.
ObjC or anything else, in a GUI ABM app.  Eclipse uses SWT, and the
difference between Eclipse and (e.g.) Forte in terms of display updating is
really noticeable--Forte feels like Java, Eclipse (after the JVM startup)
feels like native code.

SWT is open-source: you can get the SWT source from the Eclipse site
(www.eclipse.org) -- download the IDE, and the source is included.  Here's a
little more on SWT, for those interested--from
http://www-106.ibm.com/developerworks/linux/library/j-nativegui/index.html?d
wzone=linux.  It doesn't talk about performance, but you can see where using
native widgets might speed things up a bit:

The Standard Widget Toolkit
This is all great, but as Martyn points out, GCJ doesn't yet support AWT or
Swing. So how are we going to make natively compiled GUI applications? Enter
the Standard Widget Toolkit (SWT). This API is part of the open-source
Eclipse tool platform. At risk of starting a Swing-versus-SWT war (see
Resources for more on this debate), let me explain a few of the advantages
of SWT.

SWT attempts to make up for the shortcomings of AWT and Swing. With AWT, we
are left with the least common denominator limitation: only widgets that
exist on all platforms are supported. So, because Motif doesn't supply a
native tree widget but Windows does, AWT does not include a tree widget.

Swing goes to the other extreme. Although elegantly designed with a
wonderful API, Swing implements widgets on its own. Thus, Swing is not
dependent on the OS to supply widgets. This gives Swing incredible
flexibility regardless of native support. However, because Swing is drawing
these widgets itself, the resulting look and feel is often noticeably
different than native applications.

SWT attempts to bridge the gap between these two GUI toolkits. Its marching
orders are: "If there is a native widget, use it. If not, emulate it." An
example of this is the tree widget mentioned earlier. Because Windows
supports a native tree widget, SWT uses it when running on Windows. However,
Motif does not support a tree widget, so SWT draws its own version of the
widget when running under Motif. With SWT, resulting applications look very
similar to their native friends since native widgets are used as much as
possible.



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================