Piccolo.Java, Piccolo.NET and
There three versions of Piccolo:
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
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
although it is possible to use Piccolo.Java without an IDE.
Piccolo.NET, on the other hand, is written in C# and relies on
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
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.
|Piccolo Version Differences
||.NET Compact Framework
|IDE of Choice
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
release of Piccolo.NET includes an implementation of
Direct3D renderer package.
For better performance with Piccolo.Java, you can use
Agile2D, which includes a pluggable
implementation of Java2D.
PocketPiccolo.NET is our first alpha release targeting the .NET
Compact framework. As such, it has not yet been optimized for
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.
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
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:
||//Piccolo.NET and PocketPiccolo.NET
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
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
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
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
and then attach your event handler method directly to it's
delegate. For code examples see the
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.
Ease of Use
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:
- ZRectangle - This is the ZVisualComponent abstraction
- ZVisualLeaf - This is a ZNode that is used to place a
ZVisualComponent into a scene graph
- 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:
- 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
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
- 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
- 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
Jazz has some features that will most likely never be supported
- 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
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
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
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.
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
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.