There three versions of Piccolo: Piccolo.Java, Piccolo.NET, and PocketPiccolo.NET. They contain the same core functionality with a few differences.  We will examine those differences here.

Languages, Libraries and IDEs

Piccolo.Java is written in 100% java and relies on the Java2D API for graphics rendering.  Applications built on Piccolo.Java will run anywhere java will run (including Windows, Mac OS X, Linux and Solaris).  The recommended development environment for Piccolo.Java is Eclipse, although it is possible to use Piccolo.Java without an IDE.

Piccolo.NET, on the other hand, is written in C# and relies on the GDI+ API for graphics rendering.  It runs on platforms that support the .NET Framework.  However, currently only Windows machines implement the Common Language Runtime (CLR).  So, If you really want your application to be cross-platform you should use Piccolo.Java.  On the other hand, the advantage of using Piccolo.NET is that it will allow you to easily integrate advanced 2D graphics and zooming with standard Windows application code and platform-specific features.  The recommended development environment for Piccolo.NET is Visual Studio.NET.

PocketPiccolo.NET is also written in C#.  It runs on platforms that support the .NET Compact Framework (including Pocket PCs, Pocket PC Phones, Smart Phones, and Windows CE.NET devices).  There is no equivalent to GDI+ for the Compact Framework.  Thus, PocketPiccolo.NET is limited by the primitive drawing routines available through the Compact Framework.  See the Features section for more details.  As with Piccolo.NET, the recommended development environment for PocketPiccolo.NET is Visual Studio.NET.

Below is a chart the summarizes the differences outlined above.

Speed/Memory

In terms of both speed and memory usage, Piccolo.Java and Piccolo.NET are comparable.  While earlier versions of .NET had slower image rendering performance than Java, we have not done any direct comparisons in several years.  In practice, we find Java and C# to have similar rendering performance.

Since performance is critical in a graphics toolkit, we provide framework support for plugging in other more powerful renderers.  The current release of Piccolo.NET includes an implementation of a Direct3D renderer package.  For better performance with Piccolo.Java, you can use Agile2D, which includes a pluggable OpenGL implementation of Java2D.

PocketPiccolo.NET is our first alpha release targeting the .NET Compact framework.  As such, it has not yet been optimized for performance.

Features

Piccolo.Java and Piccolo.NET support virtually the same feature set.  This makes it very easy port code from one version to the other. There are however a couple exceptions:

• Transparency - Piccolo.NET does not have built-in support for transparency since .NET does not provide a mechanism to set a global alpha composite. You can of course still use transparent fills on nodes.
• PStyledText - This is a node used to render styled text data at various magnitudes.  It is available in Piccolo.Java, but not Piccolo.NET
• PStyledTextEventHandler - This is an event handler that places a text editor on the screen when a user clicks on a PStyledText node, in order to edit the underlying text.  It is available in Piccolo.Java, but not Piccolo.NET.
• PLine - This is an implementation of a line node, very similar to PPath, that was submitted by a Piccolo user.  It is available in Piccolo.Java, but not Piccolo.NET.  However, if someone ports and submits a Piccolo.NET version we will include it in the source.
• SWT Package - This is a set of classes to help integrate Piccolo code into the Eclipse development environment.  It is available in Piccolo.Java, but not Piccolo.NET.
• PFixedWidthStroke - This is stroke class that always has a fixed width on screen, even when the canvas view is zoomed.  It is available in Piccolo.Java, but not Piccolo.NET since there is no simple way to implement a Pen in .NET.

• PiccoloDirect3D - This is an implementation of Piccolo that uses a Direct3D renderer.  It available in Piccolo.NET, but not Piccolo.Java.  However, you can use Agile2D to plug in an OpenGl renderer for Piccolo.Java.
• Serialization Surrogates - These are several classes that define how to serialize certain types, to avoid duplicating serialization code.  These are available in Piccolo.NET, but not Piccolo.Java.  Piccolo.Java uses utility methods to achieve the same effect.
• PControl - This is a PNode wrapper for standard controls, allowing you to embed existing widgets (i.e. buttons, textboxes, etc.) in the scene-graph.  It is available in Piccolo.NET, but not Piccolo.Java
• PControlEventHandler - This is an event handler that implements focused based navigation for PControl nodes.  It is available in Piccolo.NET, but not Piccolo.Java

Just as the .NET Compact Framework is a subset of the .NET Framework, PocketPiccolo.NET is a subset of Piccolo.NET.  It has the same core features: hierarchical transformable objects, animation, event handling and efficiency mechanisms.  But, some features of the desktop versions are not available:

• High Quality Rendering - This refers to aliasing and other techniques that improve the quality of the rendering.  These optimizations are not available in PocketPiccolo.NET since they are not supported by the Compact Framework.
• Transparency - This is unavailable in PocketPiccolo.NET since the Compact Framework does not support transparency.
• Rotation - This is unavailable in PocketPiccolo.NET since the Compact Framework does not support rotation.
• PPath - This is a graphical path node in the desktop versions of Piccolo. In Piccolo.Java, PPath wraps the GeneralPath object and in Piccolo.NET, it wraps the GraphicsPath object.  Since there is no equivalent class to wrap in the Compact Framework, PPath is very limited.

API

The APIs for the various versions of Piccolo will all feel similar.  In fact, the PocketPiccolo.NET API is mostly identical to the Piccolo.NET API, except that some of the classes and methods of the desktop version are unavailable.  There are also some differences between Piccolo.NET and Piccolo.Java that reflect an effort to support the individual style guidelines and language constructs of Java and C#.

Method names, for example, begin with a lower-case letter in Piccolo.Java and an upper-case letter in both Piccolo.NET and PocketPiccolo.NET.  For example, the method that animates a node from it's current position and size to a new position and size is animateToBounds() in Piccolo.Java and AnimateToBounds() in Piccolo.NET and PocketPiccolo.NET.

Member attributes are also accessed differently in each API.  For example, in Piccolo.Java, attributes are accessed via get/set methods.  But, Piccolo.NET and PocketPiccolo.NET take advantage of language supported Properties. For example, to access the bounds of a node in each version you would do the following:

The APIs also differ in terms of the underlying types they use.  Often the Java and .NET names of equivalent classes are different.  For example, Java has Paint and Stroke classes whereas .NET has Brush and Pen classes.  Another example is the affine transform type, which is called AffineTransform in java and Matrix in .NET. The names of Piccolo methods also reflect these differences.  For example, the method to animate a node to an arbitrary affine transform is animateToTransform() in Piccolo.Java and AnimateToMatrix() in Piccolo.NET and PocketPiccolo.NET.

One very important distinction related to types has to do with how the bounds of a node is stored.  In Piccolo.Java there is a PBounds type which extends Rectangle2D.Double, adding several useful methods. But, the corresponding RectangleF type in .NET cannot be extended.  This left us with two choices: create a PBounds class that wraps a RectangleF or use the RectangleF directly.  We decided it would be more straightforward to store the bounds as RectangleF objects.  Thus, we provide the same methods of Piccolo.Java's PBounds as static utility methods in Piccolo.NET.

The versions of piccolo differ in the primitive types they use too.  Since the Java2D API uses doubles, Piccolo.Java also stores internal values (e.g. x, y, width, height) as doubles.  The GDI+ API on the other hand uses floats.  So, Piccolo.NET stores these same values as floats. 

Another language difference reflected in Piccolo is that Java provides anonymous inner classes while C# has delegates. The Piccolo.Java API does not enforce the use of anonymous inner classes, but, often it is the easiest way to do things.  For example, using anonymous inner classes, you could create a new type of PBasicInputEventHandler in place and override just the mousePressed method.  In Piccolo.NET, you would have to create a named static class that extends PBasicInputEventHandler to do the same thing.  This could vastly increase the amount of code you have to write.  So, Piccolo.NET provides delegates as a shorthand. This allows you to instantiate a PBasicInputEventHandler, and then attach your event handler method directly to it's MouseDown delegate.  For code examples see the Piccolo Patterns section.

Piccolo.NET also takes advantage of several other usability enhancements .NET provides, including a simpler event model, indexers, the foreach loop and type-safe lists.  See the API documentation for more details.

Piccolo and Jazz

Jazz was our previous ZUI toolkit.  The following section outlines the major differences between Piccolo and Jazz.

Our goal with Piccolo was to create a ZUI that had a similar feature set to Jazz, but that was easier to use from a programmers standpoint. Almost all the differences between Piccolo and Jazz are changes that are meant to make Piccolo easier to use.

The Jazz framework design is modeled after a 3D scene graph API. It contains many different types of object, each with specific functionality, and these objects are designed to be put together at runtime to produce more complicated objects. This gives the framework flexibility, but requires many different classes and levels of abstraction to support, making it more difficult to use. For example to create a moveable rectangle with Jazz you will need:

1. ZRectangle - This is the ZVisualComponent abstraction
2. ZVisualLeaf - This is a ZNode that is used to place a ZVisualComponent into a scene graph
3. ZTransformGroup - This is a decorator on the ZVisuallLeaf that gives it the ability to be scaled and translated.

Piccolo takes a different more traditional 2D approach. There is no separation between ZVisualComponents and ZNodes. So the Piccolo version of a rectangle extends directly from PNode and can be place directly into a scene graph without needing to be wrapped in a ZVisualLeaf type object. Piccolo has also built many of the most common decorator classes used in Jazz directly into the PNode class. For example every PNode has a affine transform, supports children, and can have its transparency set. So in Piccolo to create a movable rectangle all you need is a:

1. PPath - This class represents a graphics path and is used to draw all shapes. It extends from PNode so it has a transform, may have child nodes added to it and all the rest.

Since the Piccolo is a complete rewrite, and a smaller code base we also put a lot of time into making the Piccolo source code as readable and strait forward as possible. It's our hope that this should make it much easier to add your own new features to Piccolo then it was to do with Jazz.

The speed differences between Piccolo and Jazz for most applications are not large, most time is still spent painting with Java's Graphics2D. With that said Piccolo has made significant improvements in the time required to manipulate the scene graph. So if your program is moving around larger numbers of nodes at the same time then Piccolo should be faster.

It turns out that for most cases Piccolo uses less memory then Jazz. Since instead of needing three different objects to support the normal situation of a movable visible object it only needs one. This together with better bounds management also makes it much faster to create a large number of new objects in Piccolo then in Jazz.

The piccolo.jar size is approximately 65k, while the jazz.jar was about 450k. So for applet based applications the Piccolo framework will be much faster to download over the web.

Piccolo and Jazz support the same basic feature set. They both have structured graphics, and cameras that can look onto that structure using a view transform. So you should be able to build anything in Piccolo that was possible in Jazz. At the moment their are some specific features that we have not ported over to Piccolo from Jazz yet:

• ZAnchorGroup - used to specify hyperlinks
• ZClipGroup - used to specify a clip group around it children nodes
• ZConstraintGroup - used to constrain a transform based on some calculation. See Piccolo Patterns for an easier way to do this in Piccolo.
• ZFadeGroup - all piccolo nodes support transparency, something that ZFadeGroup was used for. But ZFadeGroup also supported automatically changing an objects transparency based on scale that it was being viewed at.
• Layout managers - Piccolo doesn't come with any layout managers, but all PNodes have a method layoutChildren() that is easily overridden and will get called for you automatically when the size of any of the children changes.
• ZSelectionGroup - Used by Jazz's selection management system. 
• ZSpatialIndex - Used for efficient picking and culling objects that won't be painted. Not having this effects speed very little if at all since the vast majority of time is spent painting objects, not culling or picking them.
• ZSwing - Piccolo does not support embedding Swing objects into the PCanvas.

Any needed features should be fairly easy to port to Piccolo, please let us know if you need something and well do our best to include it. We will put most of these features in piccolox (Piccolo extras) so that if we do add them the don't complicate Piccolo's core classes.

Jazz has some features that will most likely never be supported by Piccolo

• Text file format. Our recommendation is that applications that need a file format should use define their own and it will make life much easier for everyone. Piccolo does support Java serialization for short term persistence.

To learn more about the difference between Jazz and Piccolo and why we made this architectural change, you can read Toolkit Design for Interactive Structured Graphics.

Piccolo and Other Toolkits

There are numerous graphical toolkits available.  This section will explain how Piccolo fits in with the myriad of other available toolkits.

Structured Architecture

Piccolo is a toolkit for building structured 2D graphics programs.  This means piccolo maintains a hierarchy of visual nodes that can be grouped, oriented and manipulated in interesting ways.  As such, it is very useful for application developers who wish to build custom user interface components and smoothly integrate them with standard application code.  Most standard 2D UI toolkits provide little support for building custom components.  There are a number of other structured graphics toolkits available.  But, many provide a fixed set of shapes that can be added to the canvas, making it difficult to define new classes of objects.

There are also a number of information visualization toolkits available, such as the InfoVis Toolkit, which take a different approach.  Rather than maintaining a hierarchy of visual nodes, these toolkits walk along some application-defined data structure, visualizing each item along the way.  This approach is simple and it works quite well for visualizing information.  Since the data is decoupled from the visualization algorithm, it is also very easy to plug-in new visualizations.  But, this sort of toolkit is not as amenable to creating highly customized interaction.

Monlithic Design

Most 3D Graphics toolkits use a polylithic design approach.  This means many distinct classes are used to represent both visual and non-visual data.  Instances of these classes are then combined at runtime to create more complex objects.   This approach is very flexible.  And, it promotes abstraction and code reuse.  For this reason, some 2D graphics toolkits, such as Jazz and Prefuse, incorporate aspects of polylithic design to varying degrees.  But, this approach often results in a proliferation of types, which can be very confusing for a programmer to manage.

Piccolo takes a more traditional 2D graphics approach, using compile-time inheritance to extend functionality.  Piccolo defines a large base class that supports all of the functionality commonly used by different types of visual nodes.  New node types are created by extending this base class.  We believe this monolithic design approach is much easier for the application developer to use.

Multiple Views, Zooming and Panning

Part of the goal of piccolo was to build a toolkit that would enable highly innovative visualization and interaction.  To that end, Piccolo provides support for multiple cameras, arbitrary node transforms and full-screen zooming and panning.  This makes it very easy to build sophisticated data displays, from fisheye visualizations to Zoomable User Interfaces.  A number of other toolkits provide support for building innovative visualizations.  But, few provide the same level of support for multiple views, zooming and panning.