Optimizing the performance of JViews Framework

If your application displays and manipulates only small data sets or graphs, you don't need to worry about performance optimizations. However, an application that handles large data sets must balance between memory, speed and feature set A rich feature set often means large memory and slow speed. Using caching mechanisms may increase the speed but needs more memory. If the application uses too much memory and at the same time reacts too slow for your large data set, then you should consider reducing the features of the data set. JViews Framework includes some features and programming techniques that increase the speed and reduce the memory at the same time, however, not all features can be applied to every application.

Configuring the Java Virtual Machine

Rogue Wave® JViews allows you to create Java™ applications. As a rule of thumb, it is recommended to run the application with the latest release of the Java Virtual Machine. History has shown that past Java Virtual Machines JRE™ 1.3, JRE 1.4, and JRE 1.5 have increased the performance with each release. Therefore, the latest release is usually the fastest one.

To stop memory garbage collection that slows down the Java Virtual Machine for your custom application:

1. Set the initial heap size to the amount of memory used when the application is running in its cruise state.

2. Set the initial and final heap size using the -Xmx and -Xms command line parameters for the JVM™.

Minimizing JAR files

Rogue Wave® JViews provides several large JAR files for your application. In your application you might want to reduce the size of the JAR file, because your application does not require all classes contained in the JAR files.

1. Unpack the JAR file.

2. Remove the unused classes.

3. Create a new JAR file with only the remaining used classes.

Various commercial tools can help you reduce the JAR files automatically:

DashO: http://www.preemptive.com

JShrink: http://www.e-t.com/jshrink.html

ProGuard: http://proguard.sourceforge.net

JoGa: http://www.nq4.de/

Choosing the best graphic object

The JViews Framework contains several predefined IlvGraphic subclasses. They have different features and memory/speed characteristics. However, in some cases the best choice is to program a custom graphic object for your application, since the predefined graphic objects has a large generic set of features that may not be needed in your application.

Text objects

The classes IlvLabel, IlvZoomableLabel and IlvText can be used to display text. IlvLabel is the fastest and lightest text object, but it is not zoomable or rotatable and does not support multiple lines of text. If has very few features. IlvZoomableLabel is zoomable, rotatable and supports multiple lines of text. It paints the glyphs with gradient or texture paints. Hence it paints relatively slow and uses plenty of memory. IlvText is in many cases much faster than IlvZoomableLabel but it only supports uniform colors to draw the text glyphs. It supports attributed text (underline, strike-through, and so on) and multiline-wrapping. In most cases, IlvText is better than IlvZoomableLabel, although it uses plenty of memory.

Class name	Draw	Memory usage	Zoomable Rotatable	Glyph Fill	Background Rectangle Fill & Stroke	Multiline	Advanced features (attributed text, line wrapping)
IlvLabel	Fastest	Very light	No	Color	No	No	No
IlvZoomableLabel	Slow	Heavy	Yes	Paint	Yes	Yes	No
IlvText	Medium Fast	Heavy	Yes	Color	Yes	Yes	Yes

The drawing speed of IlvLabel, IlvText and IlvZoomableLable is faster if anti-aliasing is disabled. If the speed is critical, then it is better to switch the anti-aliasing off:

label.setAntialiasing(false);

IlvText and IlvZoomableLable are designed as general purpose classes, hence they have many features and require more memory. If memory is critical and there are many text or label objects, and if only few features of these objects need to be customizable, then it is better to implement a lightweight text class that contains only these few features. The implementation of the lightweight text class can delegate to a temporary allocated IlvText on the fly. An example of this mechanism is shown in the code example <installdir>/jviews-framework/codefragments/lighttext.

Shape objects

IlvGeneralPath is a generic object that can be used to draw any filled or stroked shape. However, some specialized classes for particular shapes exist and are much faster and use less memory. These specialized classes have less features than IlvGeneralPath, for instance they do not support custom strokes.

IlvLine to draw a straight line,

IlvPolyline to draw a sequence of straight line segments,

IlvSpline to draw a sequence of spline segments,

IlvRectangle to draw a filled or stroked rectangle, optionally with rounded corners,

IlvPolygon to draw a filled or stroked polygon,

IlvArc to draw a partial circle, annulus or pie,

IlvEllipse to draw a filled or stroked full circle or ellipse.

If these classes fit the need of your application, we recommend to use them instead of IlvGeneralPath.

Icons and images

Rogue Wave® JViews allows you to load GIF, JPG, PNG images, and, with limitations, also SVG and DXF images. GIF, JPG and PNG are bitmap formats that are loaded into IlvIcon. SVG and DXF are vector formats that can be loaded into an IlvGraphicSet (for example, in JViews Diagrammer via get. When zooming bitmaps, you loose drawing quality. For instance, a magnified bitmap may appear blurred. This effect does not occur with vector formats; they can be zoomed freely. However, vector formats use more memory and may be drawn slower than bitmaps. Assume you have 10000 nodes displaying an image consisting of 3 rectangles and 4 circles. If you load this image as bitmap, it is shared among all 10000 nodes automatically. If you load the image as SVG or DFX file, you have 10000 instances of IlvGraphicSet, each containing 3 rectangles and 4 circles: overall 30000 rectangles and 40000 circles. Therefore, implementing these nodes with SVG or DXF files will require much more memory then implementing them with bitmap images. Note that many external SVG tools produce not optimized SVG code that can be very complex. These tools are suited to create an image that is used one time, but they may not be suitable to produce images that are replicated 10000 times in 10000 nodes. Therefore, if SVG is used inside a large number of nodes, we recommend to fine-tune and to simplify the SVG, or to use bitmap images instead. To overcome the quality loss in zoomed bitmaps, IlvIcon has a high quality rendering mode (setHighQualityRendering). However, this drawing mode is very time consuming. If you need to display many icons, it is recommended to disable the high quality rendering mode to improve the performance.

NOTE >> For JViews Diagrammer IlvGeneralNode uses internally IlvIcon when needed, and it sets them by default in slow high quality rendering mode. To disable this effect, call

IlvGeneralNode.High_Quality_Icons = false;

before the first IlvGeneralNode is allocated, that is, at the beginning of your application.

Links

Rogue Wave JViews offers many link classes to connect nodes in a diagram. The simplest link class is IlvLinkImage, the most complex, feature-rich and slow link class is IlvGeneralLink from JViews Diagrammer. In terms of features, memory and speed, the following equation holds:

IlvLinkImage << IlvPolylineLinkImage < IlvEnhancedPolylineLinkImage << IlvSimpleLink (Diagrammer) << IlvGeneralLink (Diagrammer)

If your application uses many links, it is recommended to use the lightest possible link that has the features that you need:

IlvLinkImage is suitable as straight link with simple arrowhead and uniform color. Do not use it if you want to apply the automatic graph layout algorithms that reshape links available with JViews Diagrammer.

IlvPolylineLinkImage is a link with bend points. It has a simple arrowhead, a uniform color, and can be used in all graph layouts.

IlvEnhancedPolylineLinkImage has all features of IlvPolylineLinkImage. Additionally, it can display a simple backward arrowhead, has an orthogonal and bundle mode and can display tunnel/bridge crossings.

IlvSimpleLink is an IlvEnhancedPolylineLinkImage that supports property notifications that are sometimes necessary in SDM.

IlvGeneralLink has all features of IlvSimpleLink, but enables arbitrary decorations and labels, and various nonuniform colors.

IlvCompositeLink does not fit into this feature hierarchy as it has not all the features of the previously mentioned links. It can be composed by using one of the previously mentioned links. In terms of memory, IlvCompositeLink is the most heavy link. In terms of speed, it depends on the part it is composed of.

If you use the IlvClippingLinkConnector and want to improve the speed, always use a subclass of IlvPolicyAwareLinkImage (for example, IlvEnhancedPolylineLinkImage, IlvSimpleLink, or IlvGeneralLink) because the link connector can cache the clip points for these classes but not for the other link classes. If the clip points are not cached, they must be recalculated on the fly when drawing the link, and this can be slow.

If the quadtree is enabled, then zoomable links are drawn and manipulated faster than nonzoomable links (see zoomable). If your application uses many links, it is recommended to use zoomable links. Note that IlvGeneralLink is not zoomable, and other links are zoomable only if their end nodes are zoomable. If your application needs to display a huge number of links, it is recommended to use only nodes and link that are zoomable. In particular, if you use tunnel/bridge crossing shapes (of IlvEnhancedPolylineLinkImage, IlvSimpleLink, and IlvGeneralLink) you should use zoomable links because in these cases the crossings of links must be calculated on the fly. The quadtree helps to determine these crossings, but this works only if the quadtree is enabled and the links are zoomable. If the quadtree must be disabled or if you must use a large number of nonzoomable links, it is recommended to disable the tunnel/bridge crossing shapes.

Nested managers and graphers

When managers (IlvManager) or graphers (IlvGrapher) are nested in a hierarchy, the larger the depth of this hierarchy, the smaller the performance. Avoid nested graphs with an extremely high (hundreds or more) nesting depth.

When you have nested graphers, you can have intergraph links, that is, links with end nodes in different graphers. Intergraph links are often less efficient than normal links with end nodes in the same grapher, since when calculating the geometry of the link, the different transformers of the different graphers need to be taken into account. You can optimize the speed by avoiding intergraph links and by structuring your diagram in a way so that only normal links are necessary.

Implementing a custom graphic object

The most effective way to optimize speed and memory usage is to implement a custom graphic class that contains exactly the features that are needed by your application. This reduces the memory, because your custom graphic needs to store only those parameters that are variable in your application. As opposed to the generic predefined graphic classes, all other facilities (such as colors, paints, strokes, and so on) can be hard-wired if they do not need to be variable in your application. Since hard-wired facilities don't need to be stored per object, they need no memory.

There are two strategies to implement a graphic object that has multiple states and that need to be drawn in a different way:

compose an IlvGraphicSet or IlvCompositeGraphic with multiple subobjects such as IlvRectangle, IlvEllipse, IlvText and rearrange these subobjects depending on the state. It may make subobjects visible or invisible depending on the state.

create a custom graphic that simply displays different bitmap images depending on the state. There is only one bitmap image needed per state.

If you have many objects but only few states, the second strategy uses in many cases less memory because the images can be shared among all the objects, while the first strategy requires individual subobjects for each main object. The predefined class IlvMultipleIcon helps to implement the second strategy.

When implementing a custom graphic, you should optimize the following methods for speed as they are used quite frequently:

If heavy computations are needed inside boundingBox(IlvTransformer), consider implementing a cache that maps the transformer to the bounding box. The bounding box cache must be invalidated whenever the real bounds of the object change, for instance when any object parameter changes by affecting the size or position of the object. If the transformer is not in the cache, the bounding box must be recomputed. However, if the transformer is already in the cache, the bounding box can be retrieved from the cache, which speeds up the operation.

For more information on how to implement custom graphic objects see Creating a new graphic object class. The sample <installdir>/jviews-framework/samples/graphics shows how to create a custom graphic object. The code example <installdir>/jviews-framework/codefragments/lighttext shows how to create a light custom text object.

Drawing performance in the view

Sometimes the drawing performance is still not sufficient despite a careful selection of object classes. This may in particular happen if you display a huge number of objects in multiple views. Since after each change, each view must be drawn, the drawing performance may be a bottleneck. In general, the best way to improve the drawing performance is to display only one view. However, a very common scenario is to have a main view and an overview.

Redraw sessions

Whenever an object changes, the view must be redrawn to display the objects correctly. If many objects change at the same time, it is better to perform only one redraw at the end instead of many redraw after each object. This can be achieved with a redraw session:

manager.initReDraws();

try {

...many objects change, but redraw is suppressed now ...

} finally {

// redraw the views

manager.reDrawViews();

}

For details, see Optimizing drawing tasks.

Buffering the view

You can use one of the predefined view buffering techniques. A buffered view is drawn faster than each individual object contained in the view. On the other hand, updating the buffer may be slow, therefore buffering is better if objects change only rarely.

Double buffering (setDoubleBuffering) should be used to buffer the entire view. It improves scrolling performance in optimized view translation mode (setOptimizedTranslation). For details, see Managing double buffering.

Triple buffering (setTripleBufferedLayerCount) can be used to buffer the first few layers of a view. This is useful if moving objects are drawn in front of a static background. The layers 0 to n may contain the background, and the layers n+1, n+2 and so on contain the moving objects. It improves the overall drawing performance since the layer 1 to n are quickly copied from the buffer bitmap. However, the memory consumption increases by one additional in-memory bitmap of the size of the view. For details, see Triple buffering layers.

Layer caches (setLayerCached) can be used for the same reason, if the static layers that never change are not in a continuous range from 1 to n. Each cached layer requires an additional in-memory bitmap. It can be combined with triple buffering: if the static layers are 0, 1, 2, 3, 5, and 7, then use triple buffering for layer 0-3, and a layer cache for layer 5 and layer 7. If you use individual layer caches for layer 0-3, it would require more bitmap buffers than when combining these layers by triple buffering. For details, see Caching layers.

Optimizing the overview

The overview is a secondary view that is typically be used to navigate in the main view. The overview usually displays the entire manager in a demagnified way. The overview is a performance bottleneck because:

it needs to all many objects

it needs to fit the view whenever the manager contents changes

When displaying a huge number of objects, the overview may consume so much time that the application becomes unresponsive. On the other hand, the display of the overview in many situations does not need to be very precise. This can be used to improve the performance:

the overview does not need to be refreshed as often as the main view. Use the repaint skip mechanism (setRepaintSkipThreshold) to refresh the overview only every couple of seconds.

you may consider to disable blinking for the overview (setBlinkingMode). Blinking objects require periodical drawing of the view, which is the more time consuming the more objects are displayed.

if you implement your own graphic objects, then modify the draw method (draw) to draw only small rectangles when the view is demagnified. Drawing rectangles is faster than drawing nodes in full detail. At large demagnification, these details are anyway not visible. By checking the zoom factor of the input transformer of the draw method, you can easily decide whether the object needs to be drawn in full detail or only approximately as rectangle. An example of this technique can be found in the code example <installdir>/jviews-framework/codefragments/lighttext.

Expensive drawing

Views with expensive drawing and frequent updates of minor parts can be slow.

Expensive drawing means that the time to redraw the entire view can be quite long, due to a large number of objects or objects with a high graphic quality (anti-aliasing, gradients, text, or similar).

Frequent updates mean 10 updates per second or more.

The slowness can come from the default Swing RepaintManager. By default, this manager combines the areas to be updated, preferring to update one large rectangle rather than two separate small rectangles. While this is a useful heuristic in a GUI that redraws itself quickly, it can be a performance bottleneck in combination with JViews.

Rogue Wave® JViews provides a substitute RepaintManager in the class IlvExpensiveDrawingRepaintManager. It can greatly reduce the time needed for a redraw, by applying more advanced heuristics to determine which area to redraw. It can be customized to take into account the average size of the objects on screen or the type of diagram.

Blinking

Rogue Wave JViews supports blinking objects, blinking colors and blinking actions (see Blinking of graphic objects). An object that blinks needs to periodically be drawn. Here are several hints to improve the performance:

Do not use any kind of blinking if it is not necessary.

If you have blinking objects, ensure that all objects use the same blinking timing. In this case, all objects are drawn at the same time, which is more efficient than when different objects are periodically drawn at different times.

Enable blinking only in the main view. Disable blinking for secondary views such as the overview. See setBlinkingMode.

Blinking actions can modify objects periodically in an arbitrary way, which can be very inefficient. Avoid blinking actions that modify the bounding box of the graphic objects.

Consider using the IlvExpensiveDrawingRepaintManager in combination with blinking. Blinking periodically repaints regions of the view. The default RepaintManager has a simple strategy to combine regions that need repaint. The IlvExpensiveDrawingRepaintManager has an advanced strategy that is optimized in case the repaint of individual graphic objects is very expensive.

Grid and background pattern

When the grid is enabled in a manager view, it consumes a lot of graphic resources. To improve performance do not enable the grid in your view. You disable the grid by calling setGrid.

Views can also have background pattern. Similar to the grid, they consume a lot of graphic resources. You disable background pattern by calling setBackgroundPatternLocation.

The drawing of the view is most efficient if the background of the view is drawn just with a uniform color, without grid or background pattern.

Events and listeners

Rogue Wave® JViews supports various types of events and allows applications to add listeners to react on events. In many cases, these custom event listeners are the performance bottleneck, not the Rogue Wave JViews internal code. Therefore it is necessary to design the listener code carefully and to avoid to install too many listeners.

Adjusting sessions

Most Rogue Wave JViews events support an adjusting flag: large changes in the data may trigger a sequence of events, and the adjusting flag indicates that all events belong to the same sequence. This allows you to implement listeners so that inexpensive operations are done for each single event, and expensive operations are only done at the end of the sequence of events. All Rogue Wave JViews internal listeners are designed in this manner, and it is recommended that you use the same design principle for your own listeners if possible.

If your application performs large changes in the manager, then we recommend to use adjusting sessions in the following way:

manager.setContentsAdjusting(true);

try {

... add, remove, move a lot of objects...

} finally {

manager.setContentsAdjusting(false);

}

All events fired inside this adjusting session have the adjusting flag enabled, hence all listeners supporting the adjusting flag will be executed in optimized way. For more information, see Listener for the content of the manager.

If your application selects or deselects a large set of objects, use selection adjusting sessions in a similar way:

manager.setSelectionAdjusting(true);

try {

... select or deselect a lot of objects...

} finally {

manager.setSelectionAdjusting(false);

}

NOTE It is very common to combine adjusting sessions and redraw sessions:

manager.setContentsAdjusting(true);

manager.initReDraws();

try {

... add, remove, move a lot of objects...

} finally {

manager.setContentsAdjusting(false);

manager.reDrawViews();

}

If you use JViews Diagrammer, you don't need to use the low level API IlvManager.setContentsAdjusting but should use the higher-level API instead: IlvDiagrammer.setAdjusting and IlvSDMEngine.setAdjusting. These higher level API will automatically manipulate the contents adjusting and selection adjusting flag of the manager.

Implementing listeners for adjusting sessions

If you need to implement an event listener, it is recommended to perform quick tasks inside adjusting sessions and slow tasks only at the end of adjusting sessions. This ensures that the slow tasks are not performed too often and don't slow down the entire application. Here is a typical scheme for a listener:

listener = new ManagerContentChangedListener() {

int numAdditions = 0;

int numRemovals = 0;

public void contentsChanged(ManagerContentChangedEvent evt) {

if (evt.isAdjusting()) {

// inside an event series: quick operation, e.g. updating a counter

switch (evt.getType()) {

case ManagerContentChangedEvent.OBJECT_ADDED:

numAdditions++;

break;

case ManagerContentChangedEvent.OBJECT_REMOVED:

numRemovals++;

break;

}

} else (evt.getType() == ManagerContentChangedEvent.ADJUSTMENT_END) {

// at the end of the series: can do a slow operation

reorganizeSomeData(numAdditions, numRemovals);

numAdditions = numRemovals = 0;

} else {

// outside a series of events, need to do the full operation immediately

switch (evt.getType()) {

case ManagerContentChangedEvent.OBJECT_ADDED:

reorganizeSomeData(1, 0);

break;

case ManagerContentChangedEvent.OBJECT_REMOVED:

reorganizeSomeData(0, 1);

break;

}

Dispatch listeners

If you implement your own graphic object, then sometimes you want to perform some code when the graphic object itself is selected. You could register the graphic object itself as a selection listener, but when you add 1000 objects of this kind to a manager, the manager will have 1000 selection listeners. In this case it is more efficient to use a dispatch listener: one listener for all 1000 objects, that dispatches the event to the selected object. Rogue Wave JViews contains an abstract auxiliary class IlvManagerSelectionDispatcher that is suitable to implement such a dispatch listener.

Interactors

Opaque interaction mode

The select interactor (IlvSelectInteractor) and some other interactors that are able to move or reshape objects (for example, IlvPolyPointsEdition, IlvReshapeSelection, IlvMoveRectangleInteractor and its subclasses) have an opaque mode. The opaque mode means that the users sees the full graphic object while it moves or changes. If the opaque mode is switched off, the user sees only a ghost drawing of the object until the interaction is finished (for example, until the user releases the mouse button when dragging). Drawing ghosts is more efficient than drawing opaque objects, in particular if a large number of objects moves. To improve performance, call setOpaqueMove(false) or setOpaqueMode(false) on any interactor that supports opaque modes.

Hit-test

A very frequent operation is to determine which object is located at a given position. It is used by the select interactor to find the selected object. However, sometimes it is also used during every mouse movement. One example is when graphic objects have tooltips. The tooltip manager must determine during mouse movements which object is under the mouse pointer, in order to display the correct tooltip. Another example is when the objects have object interactors, and the system must determine which object interactor should receive the events.

The quadtree is a data structure to optimize the hit-test. Each manager layer can have a quadtree. The quadtree is enabled by default in optimized mode, and an application that contains a large number of graphic objects should not disable the quadtree nor switch to unoptimized mode.

The quadtree optimizes the hit-test only for zoomable objects, that is, zoomable returns true (see Zoomable and nonzoomable objects). If your application uses a large number of objects, we strongly recommend that you use zoomable objects. The hit test for nonzoomable objects is considerably slower than for zoomable objects.

Tooltips

Tooltips are handled by the IlvToolTipManager central manager. When a view is registered at the tooltip manager, the tooltip manager analyses for every mouse movement which tooltip must appear. This can slow down all mouse movements. If you use many objects and have nonzoomable objects or have the quadtree disabled, the mouse movement may become too slow. In this case, try avoid using tooltips. The following code example shows how to do this on a specific manager view:

javax.swing.SwingUtilities.invokeLater(new Runnable() {

public void run() {

IlvToolTipManager.unregisterView(dashDiag.getView());

}

});

Anti-aliasing

Anti-aliasing changes the pixels along the edges of a line into varying shades of gray or in-between color in order to make the edge appear smoother. In JViews Framework, anti-aliasing is available for graphic objects containing text, such as labels and scales. Disable anti-aliasing to improve performance at the cost of a small reduction in presentation level. This can be done by calling setAntialiasing(false) in the following classes and their subclasses

Transparency

Manager layers can be drawn transparent. The following classes (and their subclasses) support transparency per object.

IlvIcon

IlvGeneralPath

IlvGraphicSet

IlvFullZoomingGraphic

IlvHalfZoomingGraphic

IlvEnhancedPolylineLinkImage

Transparency has two potential problems:

The drawing speed is considerably slower, therefore transparency should be avoided if there are plenty of objects.

The spool size when printing the contents of a view may become very large.

If these problems affect your application, we recommend to avoid transparency. If the drawing speed is fast enough and only the large spool size causes problems, one possible solution is to disable transparency only during printing. In this case, the printout might differ from the display in the view, but the spool size remains small. If you cannot disable transparency but only very few objects are transparent, consider drawing the transparent region into an opaque offscreen buffer and print the opaque buffer instead of the transparent objects to reduce the spool size. Refer to Printing for further performance hints related to printing.

Printing

Rogue Wave® JViews printing capabilities relies on the printing mechanism of the Sun™ JVM™. In some situations, the Sun JVM generates big spool files that reduce printing performance drastically. (The problem was identified and registered as bug 4314221 in the Sun bugs database). Large printer spool sizes are usually the result of the Java 2D™ printing API using the raster pipeline instead of the default PDL pipeline. The printing API makes this switch automatically if any rendering on the page requires bitmap operations. This includes transparency and gradient paints. Therefore, the developer should avoid the following rendering features to ensure that the default PDL printing pipeline is used and spool sizes are reduced:

Avoid transparency: draw only shapes and text with no alpha component. Do not draw images that have an alpha channel.

Avoid gradients and bitmap paints: use only solid color paints.

JavaSoft™ has documented additional tips and ideas for optimizing the printing in:

The JavaSoft Java2D tutorial at http://java.sun.com/docs/books/tutorial/2d/printing/index.html.

The Java2D FAQ at http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html.

Some of these optimizations are:

Do not use a PCL or a PostScript printer. If you have to use transparencies or gradients, try to print your document to a printer which is not a PCL or a Post Script?.

Reduce the resolution of the printer, for example, use 300 DPI instead of 600 DPI.

If you must use alpha, use this technique to avoid full-page rasterization:

a. Draw the non-opaque colors into an opaque off-screen image.

b. Redraw the image with alpha into an opaque image.

c. Draw the opaque image into a PrinterGraphics.

For example, in the case of a transparent bitmap you will have better performance if the actual bitmap drawn on the printer is an opaque bitmap built from the background and the transparent original bitmap (that is, build the transparent result before hand and send that result to the printer).