Piccolo2D in Comparison

Why should you use Piccolo2D and which version should you use? This section will cover the differences between Piccolo2D.Java, Piccolo2D.NET, and PocketPiccolo2D.NET.  In addition, there will be discussions of the differences between Piccolo2D and Jazz (our previous toolkit) and how Piccolo2D relates to other available toolkits.

Piccolo2D.Java, Piccolo2D.NET and PocketPiccolo2D.NET

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

Languages, Libraries and IDEs

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

Piccolo2D.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 Piccolo2D.Java.  On the other hand, the advantage of using Piccolo2D.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 Piccolo2D.NET is Visual Studio.NET.

PocketPiccolo2D.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, PocketPiccolo2D.NET is limited by the primitive drawing routines available through the Compact Framework.  See the Features section for more details.  As with Piccolo2D.NET, the recommended development environment for PocketPiccolo2D.NET is Visual Studio.NET.

Below is a chart the summarizes the differences outlined above.

Piccolo2D Version Differences Piccolo2D.Java Piccolo2D.NET PocketPiccolo2D.NET
Language Java C# C#
Underlying Framework Java 2 .NET Framework .NET Compact Framework
Graphics Renderer Java2D GDI+ Limited GDI
IDE of Choice Eclipse Visual Studio.NET Visual Studio.NET


In terms of both speed and memory usage, Piccolo2D.Java and Piccolo2D.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 of Piccolo2D.NET includes an implementation of a Direct3D renderer package.  For better performance with Piccolo2D.Java, you can use Agile2D, which includes a pluggable OpenGL implementation of Java2D.

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


Piccolo2D.Java and Piccolo2D.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:

Just as the .NET Compact Framework is a subset of the .NET Framework, PocketPiccolo2D.NET is a subset of Piccolo2D.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:


The APIs for the various versions of Piccolo2D will all feel similar.  In fact, the PocketPiccolo2D.NET API is mostly identical to the Piccolo2D.NET API, except that some of the classes and methods of the desktop version are unavailable.  There are also some differences between Piccolo2D.NET and Piccolo2D.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 Piccolo2D.Java and an upper-case letter in both Piccolo2D.NET and PocketPiccolo2D.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 Piccolo2D.Java and AnimateToBounds() in Piccolo2D.NET and PocketPiccolo2D.NET.

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

//Piccolo2D.Java //Piccolo2D.NET and PocketPiccolo2D.NET
node.getBounds() node.Bounds

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 Piccolo2D methods also reflect these differences.  For example, the method to animate a node to an arbitrary affine transform is animateToTransform() in Piccolo2D.Java and AnimateToMatrix() in Piccolo2D.NET and PocketPiccolo2D.NET.

One very important distinction related to types has to do with how the bounds of a node is stored.  In Piccolo2D.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 Piccolo2D.Java's PBounds as static utility methods in Piccolo2D.NET.

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

Another language difference reflected in Piccolo2D is that Java provides anonymous inner classes while C# has delegates. The Piccolo2D.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 Piccolo2D.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, Piccolo2D.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 Piccolo2D Patterns section.

Piccolo2D.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.

Piccolo2D and Jazz

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

Ease of Use

Our goal with Piccolo2D 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 Piccolo2D and Jazz are changes that are meant to make Piccolo2D 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:

This is the ZVisualComponent abstraction
This is a ZNode that is used to place a ZVisualComponent into a scene graph
This is a decorator on the ZVisuallLeaf that gives it the ability to be scaled and translated.

Piccolo2D takes a different more traditional 2D approach. There is no separation between ZVisualComponents and ZNodes. So the Piccolo2D 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. Piccolo2D 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 Piccolo2D to create a movable rectangle all you need is a:

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 Piccolo2D is a complete rewrite, and a smaller code base we also put a lot of time into making the Piccolo2D source code as readable and straightforward as possible. It's our hope that this should make it much easier to add your own new features to Piccolo2D then it was to do with Jazz.


The speed differences between Piccolo2D and Jazz for most applications are not large, most time is still spent painting with Java's Graphics2D. With that said Piccolo2D 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 Piccolo2D should be faster.

It turns out that for most cases Piccolo2D 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 Piccolo2D then in Jazz.

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


Piccolo2D 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 Piccolo2D that was possible in Jazz. At the moment their are some specific features that we have not ported over to Piccolo2D from Jazz yet:

used to specify hyperlinks
used to specify a clip group around it children nodes
used to constrain a transform based on some calculation. See Piccolo2D Patterns for an easier way to do this in Piccolo2D.
all piccolo2d 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
Piccolo2D 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.
Used by Jazz's selection management system.
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.
Piccolo2D does not support embedding Swing objects into the PCanvas.

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

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

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. Piccolo2D does support Java serialization for short term persistence.

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

Piccolo2D and Other Toolkits

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

Structured Architecture

Piccolo2D is a toolkit for building structured 2D graphics programs.  This means piccolo2d 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.

Piccolo2D takes a more traditional 2D graphics approach, using compile-time inheritance to extend functionality.  Piccolo2D 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 piccolo2d was to build a toolkit that would enable highly innovative visualization and interaction.  To that end, Piccolo2D 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.