Many of our users confirm that ILOG’s diagramming components are state of the art. But will our components meet the challenges of the future? Maybe we will see the answer in Chicago …

It is time again for the 16th Graph Drawing Contest, held in conjunction with the GD’2009 conference in Chicago on Sep 22-25. Like last year, I have the pleasure to be a member of the contest commitee, and I am excited to soon see the results of the challenges. One of the topics of the contest is “partial layout”. That is, given a graph with some fixed nodes, calculate a good layout while moving only the free nodes. This is a real world requirement that many of our customers have mentioned in the past. In Chicago we will see the current state of the art in partial layout, and we will hopefully get inspiration for further development within our own components. Additionally, there will again be an online contest similar to a programming contest. This is where a difficult problem must be solved online within 1 hour. If you are interested in participating in the Graph Drawing Contest, you can find further information at http://www.graphdrawing.de/contest2009/.

The first is titled Create Rich Dynamic Graphical Displays with Ajax , presented by our own Erwan Paccard and Michelle Liu.

The second is called Ajax Push Techniques for Better Data Visualization , and is presented by our Francois Trible and by IceSoft’s Ted Goddard.

Get out the popcorn and your favorite beverage, sit back, and enjoy the shows!

The presentation is at 9AM Pacific time/ 6PM Europe time and last for one hour.  More info and registration here.  Please join us.

Since JViews 8.5 we have enhanced our JSF components to completely support PPR. This is an important feature expected by our customers. Many questions have been asked around this new feature:

• For these who are not familiar with JSF PPR technologies, you might ask the questions what can PPR bring for you, what is the benefit you can draw compared to other well-known Ajax technologies, and what are the JSF platforms supporting PPR.
• For JViews Web application developers, you might worry if this has any impact on the application you have developed with previous version of JViews. Is it possible to add PPR features to existing JViews JSF Web applications without refactoring the application?
• From a technical point of view, it is also interesting to learn what the JViews Team has done to support PPR. What are the difficulties we encountered to make our JSF components PPR compatible?

Let’s go into more details for each of the topics. We suppose you are familiar with JSF technologies. At least you know how a “Hello World” JSF application works.

What is Partial Page Refresh?

When working with JSF to build Web applications, your JSF pages are composed of JSF components. Take an example, you have a JSF page composed of 5 JSF components. When the JSF page is requested by any Web browser, the 5 JSF components will be rendered to HTML and sent to the browser. When users submit data to the server and request a refresh of the page, all 5 JSF components will be rendered again and resent to the browser. The entire HTML page is refreshed even if only one of the 5 components needs to be updated because the remaining 4 JSF components are quite static. You can see now the inconvenience of a Full Page Refresh.

Partial Page Refresh gives you the ability to update a subset of the JSF components. For the above example, if only one of the JSF components has been changed, you need to only re-render one component and send just the one component to the browser. You will see only part of the HTML page refreshed not the entire page. This technique has 2 advantages: the first is to reduce network traffic and improve the performance of the Web applications; the second is to improve visual comfort because only a part of the HTML page will be refreshed.

JSF PPR and Ajax

What is the difference compared to pure Ajax technologies? This is an interesting question because Ajax has also been introduced to update subsets of HTML pages. The difference is that Ajax is designed to work at a very low level. With Ajax, you can refresh a property of a given HTML element, such as the label of the button. With JSF PPR, you are working at the JSF component level. The minimum refreshable unit is a JSF component that might be composed of several HTML elements. This means that you can get very good performance with AJAX if you need to refresh only a very small part of the HTML page. Note that JSF PPR frameworks are usually implemented based on Ajax technologies.

The advantage of JSF PPR is at the design and development level, since it allows Rapid Application Development (RAD). You can create PPR Web applications very quickly by composing standard JSF components. In JViews 8.5, we provide both JSF PPR features for RAD and also Ajax features for performance purposes.

JSF PPR Frameworks

The most popular JSF PPR frameworks are Apache MyFaces Trinidad, JBoss RichFaces, and ICEsoft ICEfaces.

With Trinidad and RichFaces, you can specify explicitly at design time which components can trigger a partial refresh and which components can be refreshed. For example, let’s say that when you click a button you want a text field to be refreshed. The button is called the trigger component and the text field is called the target component. The target components are usually chosen at design time when authoring the JSF pages. However, target components can also be chosen at runtime when rendering the JSF page. These are tasks for advanced developers.

Knowing explicitly which ones are target components is helpful when rendering JViews JSF components. Because we need to render a JViews JSF component differently, depending on whether it is rendered for the first time or it is requested to be refreshed partially. You will see later why we need to distinguish these 2 situations.

ICEfaces has a very unique approach to handling PPR requests. At design time, i.e. when you compose your JSF pages, you can not specify which components are triggers and which ones are targets. All components are potentially triggers and targets. ICEfaces uses its direct-to-DOM rendering technique to determine dynamically at runtime which components should be updated. This may seem unusual, but it gives great flexibility to JSF application developers. However, JSF components providers like us need to do much more work to support this flexibility. The good news is that we have done this hard work for JViews 8.5. JViews JSF components can be used as any other ICEfaces native components.

Another particularity of ICEfaces is its server-side initiated rendering. This allows pushing updates from the server to the browsers. JViews 8.5 JSF components works fine within the ICEfaces push lifecycle. 

JViews JSF Components Refactoring to Support PPR

JViews JSF components were initially designed to work in a static way within an HTML page. They were not initially designed to be updated after the HTML paged has been loaded.

Some JViews JSF components, such as a <jvdf:diagrammerView>, rely on the onload event of the HTML page to make themselves active. In a PPR lifecycle, JViews JSF components might be inserted into a loaded HTML page by a partial request. A typical use case is when you insert JViews components into a tab panel. When you make the panel tab visible by clicking its header, the contained JViews components will be rendered and inserted into the HTML page. However, the onload event of the HTML page will have already fired when it was initially loaded. Under this situation, we have to simulate a fake onload event to make the JViews JSF components active.

A JViews JSF component is rendered as a set of HTML elements and JavaScript codes. In a PPR environment, a JViews component can be inserted into or removed from a loaded HTML page at any moment. JViews JavaScript code might be evaluated and re-evaluated as many times as needed. The order of the evaluation of the JavaScript elements is also very important to guarantee the functionality of the JViews components. To resolve these problems, PPR frameworks such as Trinidad, RichFaces, and ICEfaces put the JavaScript code for their components in the head element of the HTML page. They can do this because they are JSF technology providers and they have entire control of the HTML page they are rendering. However, we as third party JSF components providers have absolutely no control over the HTML page. We had to reorganize our JavaScript code so that it can be dynamically loaded as many times as necessary and in the right order.  

Developing PPR JViews Web Applications

In JViews 8.5, JSF components have been refactored for supporting PPR without breaking the compatibility with previous versions. This gives developers flexibilities to add PPR features to their existing Web applications or to create new PPR Web applications.

In case you want to create new Web applications and want to benefit from PPR features, we suggests you develop your application with one of the supported PPR frameworks mentioned above. You can choose the framework of your preference that matches the functionality of your requirements. On the JViews side, Trinidad and ICEfaces are fully supported. JViews 8.5 supports RichFaces also, but has some limitations under Ajax mode. We have planned to fully support RichFaces for the next release.

In case you have developed your JSF applications with a previous version of JViews, you will be able to benefit immediately from the PPR features if you develop with one of the PPR frameworks mentioned above. If you develop with another JSF framework that does not support PPR at all, you won’t be able to benefit from the JViews PPR features. However, this does not mean that you have no choice other than doing a full page refresh, because the JViews JSF components have great Ajax features and can update themselves efficiently without invoking a full page refresh.

JavaFx Script (I will call in the following just JavaFx, for short) is a scripting language compiled into Java Byte Code. Its main purpose is the specification of GUI parts of Internet applications. It contains syntactic sugar to simplify this task, such as a declarative syntax for object containments and comfortable data binding statements. Where you need to write 40-50 lines of Java code for the data binding, you can do it in JavaFx code with just one line of code. And it is fairly easy to learn, like most other scripting languages for the Web. But at the end, it is just another way to create Java Byte Code, something that you can do with Java as well.

For us Java programmers, the big advantage of JavaFx over its competitors Flex and Silverlight is the fact that JavaFx is compatible with Java. We can call Java code from JavaFx and vice versa smoothly. That’s at least what all the hype and marketing about JavaFx promises to you. Well, let’s try with JViews whether this is really the truth!

Sample Application - First Try

The following will show how to integrate an IlvScrollManagerView into a JavaFx application and how to implement a binding between JavaFx GUI elements and graphic objects displayed in the manager view. If you are using the NetBeans IDE, the first step is to create a new JavaFx project and to add the directory containing the JLM key and the JViews libraries (jviews-framework-lib.jar is enough in this example) to the libraries of the JavaFx project.

In JavaFx, you can import and use Java classes just like JavaFx classes. There is no need to declare a top level class or a main function. Hence, the first try is easy:

 package jviews;

import java.lang.*;
import ilog.views.*;
import ilog.views.util.*;
import ilog.views.graphic.*;
import ilog.views.interactor.*;
import ilog.views.swing.*;
import javafx.ext.swing.*;
import javafx.scene.Scene;
import javafx.stage.Stage;

var grapher = new IlvGrapher();
var mgrview = new IlvManagerView(grapher);
var scrview = new IlvJScrollManagerView(mgrview);

scrview.setPreferredSize(new java.awt.Dimension(343,280));
var viewnode = SwingComponent.wrap(scrview);

Stage {
    title: "JViews Manager View Application"
    width: 350
    height: 350
    scene: Scene {
        content: [ viewnode ]
    }
}

JavaFx uses the scene graph to specify the GUI. The part Stage { ... } specifies in declarative way a scene graph containing just the manager view. You cannot use Swing components directly in the scene graph, but you can wrap them into scene graph nodes by SwingComponent.wrap(scrview). Try it and you will see the scrollable manager view inside your JavaFx application.

But it does not quite work! After filling the grapher with contents, you cannot scroll inside the manager view. IlvScrollManagerView is a complex Swing component, and SwingComponent.wrap was probably only tested on fairly simple Swing components. IlvManagerView uses bitblt operations to maximize scrolling speed, and this mechanism does not work in JavaFx. The bitblt scrolling can be switched off by

mgrview.setOptimizedTranslation(false);

but even then it fails to redraw the view when scrolling. By debugging the component hierarchy, I found that the JavaFx wrapper of the IlvScrollManagerView is a com.sun.embeddedswing.EmbeddedPeer$ShellContainer which has component bounds of size 0. The scrolling mechanism of IlvManagerView calculates the visible area by checking all component bounds and ends up with an area of size 0. Hence it thinks that nothing is visible that needs redrawing during scrolling.

Sample Application - Second Try

No reason to panic! JavaFx allows subclassing, so we can fix the problem in a subclass of IlvManagerView. JavaFx even allows multiple inheritance to some degree, but for the fix, a simple subclass ManagerView with single inheritance is good enough. Since the redraw during scrolling is missing, we override translate to call repaint explicitly. Due to the possibility of multiple inheritance, super is not a keyword in JavaFx. Instead you need to specify which super class is meant, hence the call IlvManagerView.translate in the following JavaFx code has the same meaning like super.translate in Java. The beginning of my simple JavaFx script now looks like this:

class ManagerView extends IlvManagerView {
    override public function translate(x,y,redraw) {
        IlvManagerView.translate(x, y, redraw);
        if (redraw)
          repaint();
    }
}

var grapher = new IlvGrapher();
var mgrview = new ManagerView();
var scrview = new IlvJScrollManagerView(mgrview);
mgrview.setManager(grapher);
mgrview.setOptimizedTranslation(false);

In order to be able to select objects in the manager view, we specify a select interactor. Here we hit the second problem: the select interactor works by default in ghost mode using Xor drawing routines. As mentioned in a previous BLOG entry, this does not work smoothly in JDK 1.6.0 update 10 and update 11. But unfortunately, Sun recommend exactly these JDK versions for Javafx. To work around this problem, we select the opaque mode of the select interactor:

var interactor = new IlvSelectInteractor();
interactor.setOpaqueMove(true);
interactor.setOpaqueDragSelection(true);
mgrview.setInteractor(interactor);

Sample Application - Binding JViews to JavaFx

To show how to bind JavaFx GUI elements to JViews objects, I first need to fill the grapher. I define a simple flowchart here:

var polygonpoints = [
    new IlvPoint(90,60),
    new IlvPoint(110,75),
    new IlvPoint(90,90),
    new IlvPoint(70,75) ];
var bends1 = [ new IlvPoint(30,75) ];
var bends2 = [ new IlvPoint(150,75) ];
var bends3 = [ new IlvPoint(30,155), new IlvPoint(90,155) ];
var bends4 = [ new IlvPoint(150,155), new IlvPoint(90,155) ];
var node1 = new IlvEllipse(new IlvRect(70,10,40,30));
var node2 = new IlvPolygon(polygonpoints);
var node3 = new IlvRectangle(new IlvRect(10,110,40,30));
var node4 = new IlvRectangle(new IlvRect(130,110,40,30));
var node5 = new IlvEllipse(new IlvRect(70,170,40,30));
var link1 = new IlvPolylineLinkImage(node1, node2, true, null);
var link2 = new IlvPolylineLinkImage(node2, node3, true, bends1);
var link3 = new IlvPolylineLinkImage(node2, node4, true, bends2);
var link4 = new IlvPolylineLinkImage(node3, node5, true, bends3);
var link5 = new IlvPolylineLinkImage(node4, node5, true, bends4);

node1.setFillOn(true);
node1.setBackground(java.awt.Color.pink);
node2.setFillOn(true);
node2.setStrokeOn(true);
node2.setForeground(java.awt.Color.yellow);
node2.setBackground(java.awt.Color.black);
node3.setFillOn(true);
node3.setBackground(java.awt.Color.green);
node4.setFillOn(true);
node4.setBackground(java.awt.Color.green);
node5.setFillOn(true);
node5.setBackground(java.awt.Color.pink);

grapher.addNode(node1, true);
grapher.addNode(node2, true);
grapher.addNode(node3, true);
grapher.addNode(node4, true);
grapher.addNode(node5, true);
grapher.addLink(link1, true);
grapher.addLink(link2, true);
grapher.addLink(link3, true);
grapher.addLink(link4, true);
grapher.addLink(link5, true);

Next, I define a slider. I want to control the position of a node in the grapher with this slider. JavaFx allows you to use predefined sliders in standard Swing style:

var slider = SwingSlider {
    width: 300
    minimum: 0
    maximum: 100
    value: 0
    vertical: false
    translateX: 10
    translateY: 290
};

We need to add the slider to the scene graph. The scene graph with the swing slider is now:

Stage {
    title: "JViews Manager View Application"
    width: 350
    height: 350
    scene: Scene {
        content: [ viewnode slider ]
    }
}

JavaFx offers the keyword bind to implement data binding between JavaFx attributes, but I cannot bind the node position directly to the slider value. First, the node position is not a JavaFx attribute but a field of a Java class. Secondly, you either must call applyToObject or moveObject on the manager when the object moves, otherwise the quadtree of JViews gets messed up. But we can declare an auxiliary JavaFx variable and bind it to the slider value so that the variable gets updated when the slider thumb is moved:

var position = bind slider.value ...

and with the replace keyword, we can add code that is executed whenever this auxiliary variable changes. The entire data binding is here:

var position = bind slider.value on replace {
    grapher.moveObject(node4, 130 + 3 * position, 110, true);
    grapher.applyToObject(link3, IlvApplyObject {
        override public function apply(g:IlvGraphic, arg:Object) {
            link3.movePoint(1, 150 + 3 * position, 75, null);
        }

    }, null, true);
   grapher.applyToObject(link5, IlvApplyObject {
        override public function apply(g:IlvGraphic, arg:Object) {
               link5.movePoint(1, 150 + 3 * position, 155, null);
        }

       }, null, true);
};

This causes a node and two bend points of links to move when we use the slider.

Summary

Finally it works smoothly. The applet does not yet look very fancy, but it shows the basic principle. The entire source code of this simple sample can be found here. We showed some small tricks to get it working, but overall JavaFx works very smoothly with JViews. JavaFx is an alternative for programmers to code Java components and it might grab its share of the RIA market. Right now, JavaFx is still very new, but I think it is a promising platform.

Prerequisites: This step-by-step exercise assumes that you have already installed Eclipse 3.4 with its modeling extensions (EMF, GMF and GEF), and that you have installed and integrated JViews Graph Layout for Eclipse. A full evaluation version can be requested here.

Project for Step 1 :Download this zipped Plugin Project corresponding to the first step of this exercise. You will have to import this project into your Eclipse environment. It contains a generic modeler, based on GMF. The following movie describes how to import this project (at 5 minutes and 28 seconds in the movie).

The following movie is best viewed in full screen mode:

Code Snippets: To make things easier, here are some code snippets you can use to complete the exercise:

Step1:

public class MyDiagramEditPart extends DiagramEditPart implements IGrapherEditPart {  private GMFLayoutSource myLayoutSource; // reference on the layout source implementation  public void activate() {   

    myLayoutSource = new GMFLayoutSource(this);  // BEFORE CALLING super.activate();   

    IlvHierarchicalLayout layout = new IlvHierarchicalLayout();  // Create a hierarchical layout   

    layout.setGlobalLinkStyle(IlvHierarchicalLayout.ORTHOGONAL_STYLE); // Configure layout   

    layout.setFlowDirection(ilog.views.IlvDirection.Right);   

    myLayoutSource.setGraphLayout(layout);   // Register Graph Layout configuration   

    super.activate();   

  }   

  public void deactivate() {   

    super.deactivate();   

    myLayoutSource.dispose();  // cleanup   

    myLayoutSource = null;   

  }   

  public Object getAdapter (Class adapter) {   

    if (adapter.equals(ILayoutSource.class)) {   

      return myLayoutSource;   

    }   

    return super.getAdapter(adapter);   

  }   

  public boolean isTopLevel() {   

    return true;   

  }   

}

Step2:

public class MyEditor extends DiagramDocumentEditor {  ...public void initializeGraphicalViewerContents() {   

    super.initializeGraphicalViewerContents();   

    ILayoutSource layoutSource =   

      (ILayoutSource)getDiagramGraphicalViewer().getContents().   

      getAdapter(ILayoutSource.class);   

    layoutSource.initialize();   

  }

Next Steps:

If you have completed this exercise, you can then have a look at a more complete version of a GMF-based editor, available in the Samples section of JViews Graph Layout for Eclipse. The easiest way is to display the Eclipse Welcome page (available in Help menu) and look for the GMF Editor appearing in the Samples section. You will see a more complete integration, including property editors for customizing the different layouts, persistence of your settings, and much more.

Now, Sun released Java 1.6 update 11 which did not solve the previous bug, but… introduced Sun BR 6784894 (”Regression: applets loaded from local disk can not access co-located resources”). Basically, with this Java update, and until Sun fixes this severe regression, the applets that we ship with JViews will fail to run locally (from your hard disk). Applets executed on the web are not affected.

Here is the workaround for this new bug:

1. Create a text file named .java.policy that grants “read” access to, say, your installation of ILOG JViews. An example:

grant {
  permission java.io.FilePermission "c:\\ILOG\\-", "read";
};

2. Place the file in the “home directory” of your user account.

3. Restart the browser.

We tested it, and it works like a charm.

We think Sun is working on fixing the broken applets issue as soon as possible. Since it can take quite a while until an update including the fix will be released, the workaround might come handy… Enjoy. And let’s all hope the Java platform will soon retrieve its stability.

Update: JDK 1.6 update 12 is now released, and it fixed indeed this bug.

Still, usability studies and practice teach us some valid points to remember when designing a Rich Internet Application (RIA) application. This post explains some of the issues your users may encounter and how to avoid them by following a user-centered design process.

First, let’s define what we mean by usability. Among several propositions, the ISO 9241-11 norm states that the quality aspect of usability is “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

This definition includes four elements that are necessary to create a usable system:

• There are specified users of the system.
• The users have a set of specified goals.
• The system should allow user goals to be met (effectively) in an efficient manner and the users will be satisfied with the process or outcome.
• The system will be used in a particular context (e.g. within a physical location, a business process).

A usable system is one that is designed to consider all of these aspects. This post by Donna Maurer somewhat refines this definition.

The User Mental Model in web applications

A  RIA lies at the crossroad of 2 user interface paradigms: the desktop application, or WIMP model, and the web page, or REST model. Subtle differences between those 2 models can induce confusion  when your application tries to take advantage of both. For instance, a single click on a link is sufficient to “open” the associated web-page, whereas on the desktop, one needs to double-click to open a document. Drag-and-drop is often used to perform actions on the desktop, while users usually expect clicking in a web page doesn’t go beyond selecting text. The back button in the browser is often interpreted as the equivalent of some kind of “undo” action, whereas in a RIA, the need to maintain an interaction state often precludes such interpretation.

Cognitive psychology tells us that in a particular context (here, desktop or web), users build a mental model of how to operate the interface:  they create expectations from the context to find out which operations are available and what to do next. “Like a pane of glass framing and subtly distorting our vision, mental models determine what we see.” - Peter Senge.

One of the key challenges when designing a RIA is to keep in mind that you’re trying to make the best of two worlds, while preserving a consistent interaction model is paramount. This means that somehow, you’ll need to take into account the interferences brought by those coexisting models and provide ample visual cues when you’re proposing alternate or novel interaction methods.

What kind of interactions for your web application?

Deciding what interaction methods to implement and how “rich” should your interface be is always a matter of context. For instance, drag-and-drop of panes on a portal such as igoogle is usually well accepted, because the panes have high-visibility borders, and the task to perform is the arrangement of a display quite similar to the arrangement of windows on a desktop. In contrast, on many e-commerce sites, drag-and-drop of items to the purchase cart is often a bad idea: no perceptual cues indicate that the item is “draggable” ; when the items to display don’t fit on a single screen, drag-and-drop operations interfere with the need to scroll up or down ; finally, the “remove from cart” operation is rarely implemented consistently with the “add-to-cart” method (i.e. by using a “drag to bin” operation).

Determining the context of operations leads to the notion of task. A task is a procedural description of what the user has to do, framed within the context of the user’s mental model. Designing proper interactions therefore requires making tasks explicit to determine what could or should the mental model be at any point in time. It turns out that fully eliciting tasks is extremely tedious. That’s why it is often limited to mission-critical situations, such as air traffic control. It is also of limited use in the context of web applications, as many users may come to your site with different goals and expectations.

In the design phase and for interface specifications, usability specialists often resort to usability guidelines which allow checking for user interface consistency in a reasonably efficient way. There are several levels of guidelines, from the broad recommendations on the proposed workflow to focused considerations on layout and visual appearance of widgets. J. Nielsen’s 10 heuristics, for instance, are of a very general nature and can be applied in pretty much every context. Ben Shneiderman’s direct manipulation principles are very useful and easy to use guidelines to develop highly interactive applications. On the desktop, all major constructors provide a set of user interface guidelines that are to be followed for a particular platform. In the context of the web, though, they are inapplicable, as web applications follow a “menus, lists and forms” interaction style rather than direct manipulation (this page at interactiondesign explains the stylistic differences). One can resort to some standard web design guidelines, such as the Research-Based Web Design & Usability Guidelines.

The RIA platforms are somewhat too young to have given rise to an agreed-upon body of guidelines. Flazzom, targeted at the Flash platform , but applicable for the most part to other web platforms, comes close enough to meet the needs of a web designer. Rather than guidelines, pattern libraries,  such as yahoo’s, designed by experts, help implementing usable and rich web applications: because they are used by many sites, users acquire quite rapidly the right mental model to use them with profit.

The user at the center of the design process

Still, because of their generality of purpose, guidelines are only able to provide broad rules, whose applicability and usefulness vary with the application considered. What usability specialists recommend is to put the user at the center of the design process.

Various methodologies exist to this effect: collaborative design, user testing (inside the usability lab or in situ), longitudinal studies of users in context, surveys, usage trace analysis… This table at UsabilityNet provides an interesting overview.

Choosing one or more methods is a matter of available resources, appropriateness, design stage, and, perhaps, a touch of personal taste. Still, all those methods rely on a fundamental observation: as a designer, your judgment is too biased to let you find flaws and limitations in your design, and to judge of its relevance to meet the user needs. Only target users, when carefully led to express their approach to the task, can guide you towards a design they appropriate themselves.

In summary, while RIA applications promise in general much better usability by expanding the realm of possibilities, they also raise particular usability challenges. In a large part, those challenges are the result of the additional power they give to the designer to mix and match interaction techniques and styles. We hope this post helps you get a sense of what user centered design can bring to your design activity to help you satisfy your users better and more cost-effectively. Perhaps the essential recommendation should be: just like for any other interactive application that will be used by someone else than its designer: involve your target users in the design, from start to finish.

Thomas Baudel, Sophie de Bonis & Sandra Belfils

So far so good, but using this update on Windows you might experience severe performance regressions for XOR drawing (typically used for drawing “ghosts”). This hurts our products as any other product or Java graphic app doing similar operations. Whether it actually hurts on a given machine, it may be dependent on the video card and drivers that you have installed.

Sun’s release notes warn us about this potential regression (see the section New Direct3D Accelerated Rendering Pipeline for Microsoft Windows Platforms, Enabled by Default). Sun tends to call it a “limitation”, however they classified the following as a bug: “D3D: XOR rendering is extremely slow” (don’t hesitate to vote for it). Hence, there is some hope the issue will be solved in a future update. In the meantime, you can apply the easy workaround mentioned in Sun’ release notes:

“To disable the Direct3D Pipeline, pass the following property to the Java VM: -Dsun.java2d.d3d=false. Alternatively, set the J2D_D3D environment variable to ‘false’ prior to starting your application (or set it globally).”

See also this forum discussion: “Java 2D - Problem drawing in XORMode with JDK1.6 Update 10”.

Update Dec. 4th 2008: JDK 1.6 update 11 is now available. There was hope it might fix this issue… but testing shows this is not (yet) the case.
Update May 27th 2009: Sun’s BR now has a comment saying “This bug has been resolved in 6u14b03 (early builds available from jdk6.dev.java.net).”
Update May 29th 2009: tested okay against Sun JDK 1.6.0_14 b08 on Windows.