Plenty of features … sigh! Features cost memory and performance. Each text parameter that can be customized needs to be stored in the text object, and if you have many features, you also have many parameters. Indeed, IlvText for instance uses quite a bit of memory, and if you have 100000 text objects, you can run into memory problems … that are avoidable.

Reducing the number of parameters

What if we don’t need all these customizable parameters? Let’s assume all text objects in our application display a single line each, and the only variable parameters are the color of the text and of the background rectangle, and of course the label and position of the text object. Then we need to store 2 colors, a string and a position in the text object, but not parameters such as antialiasing, font, wrapping mode, margins and so on, because these can be hard coded and are fixed for all text objects. This is the essential idea of a lightweight text: use only memory for parameters that are customizable, and avoid memory for parameters that we never want to customize in our application.

Good idea, but it sounds like a lot of effort! My new LightText class needs to render text to display it. How can I do this without writing a text rendering engine from scratch? The idea is to use the text rendering engine of IlvText. Whenever I need to draw the LightText, I allocate a new IlvText object, draw it instead, and then give it free. That is, I delegate the rendering of the LightText to a temporary IlvText object allocated on the fly. The Java garbage collection will make sure that the memory footprint remains low. The first sketch is this:

public class LightText extends IlvGraphic {
    Color foreground;
    Color background;
    IlvRect bounds;       // the current position
    String label;            // the label text
    ...

    public void draw(Graphics dst, IlvTransformer t) {
        getDelegate(true).draw(dst, t);
    }

    private IlvText getDelegate(boolean includeBounds) {
        IlvText text = new IlvText(new IlvPoint(), label));
        // hard coded parameters
        text.setAntialiasing(true);
        text.setLeftMargin(4);
        text.setRightMargin(4);
        text.setTopMargin(4);
        text.setBottomMargin(4);
        text.setFillOn(true);
        text.setStrokeOn(false);
        // customized parameters
        text.setForeground(foreground);
        text.setFillPaint(background);
        if (includeBounds)
            text.moveResize(bounds);
        else if (bounds != null)
            text.move(bounds.x, bounds.y);
        return text;
    }
}

Now LightText uses less memory, because it stores less parameters than IlvText, but of course this is not fast. When drawing the objects, delegates must be allocated, and this needs time. This does not hurt much when we draw only 10-30 objects, but when we have to draw 100000 objects, it will be much too slow.

Speeding up drawing with small zoom level

Well, 100000 objects on the screen? We only need to draw 100000 objects at the same time if the view is demagnified. Otherwise all these objects would not fit on the screen. But when the view is demagnified, each single object occupies only a tiny area and you cannot recognize the details of the object anyway. Therefore it is not needed to draw all details. In this case, it is sufficient to draw only a tiny rectangle instead of the fully rendered text. Only when the view is magnified, we need to draw the text in detail, but in this case we never need to draw many objects. Hence, when the view is magnified, the slowdown caused by the few delegate drawing does not hurt so much, and when the view is demagnified, we don’t need to allocate many delegates. Here is the modified draw routine:

    public void draw(Graphics dst, IlvTransformer t) {
        IlvRect bbox = boundingBox(t);

        if (bbox.width <= 2 || bbox.height <= 2) {
            // draw only a tiny filled rectangle
            dst.setColor(foreground);
            int w = Math.max(1, (int)bbox.width);
            int h = Math.max(1, (int)bbox.height);
            dst.fillRect((int)bbox.x, (int)bbox.y, w, h);
        } else if (bbox.width <= 4 || bbox.height <= 4) {
            // draw border and inner, but no text
            int w = Math.max(1, (int)bbox.width);
            int h = Math.max(1, (int)bbox.height);
            // fill on is hardcoded to true
            dst.setPaint(background);
            dst.fillRect((int)bbox.x, (int)bbox.y, w, h);
            // stroke on is hardcoded to false, hence only the text label,
            // not the border is drawn
            dst.setColor(foreground);
            int x = (int)bbox.x;
            int middle = (int)(bbox.y + 0.5f * bbox.height);
            dst.drawLine(x, middle, x + w, middle);
        } else {
            // draw the text via delegate
            getDelegate(true).draw(dst, t);
        }
  }

This draw method has 3 levels of details:

• If the text object is drawn on an area smaller than 2×2 pixels, we draw a filled rectangle.
• If the text object is drawn on an area smaller than 4×4 pixels, we draw a filled background rectangle and a line inside representing the text.
• Otherwise, we draw the text object in full detail.

Results

I wrote a small application that displays 10000 text objects. When using IlvText directly, the application allocates 13 MB memory. When using LightText, it requires only 2.5 MB of memory. This technique hence allowed me to reduce the memory load by a factor of 5.2. When I zoom out, the LightText actually draws faster than IlvText. When I zoom in, only few objects get drawn, hence the slowdown of LightText is in this case neglectable.

The full code of the example is available here: lighttext.zip. It compiles with JViews 8.0 and 8.1. My small application has a check box at the top to choose between IlvText and LightText, and it displays the history of the memory footprint at the bottom. When you switch from IlvText to LightText, you can easily see how the memory footprint is reduced.

LightText is not just yet another text object. It is rather a programming technique, since it depends on your application which parameters of IlvText must be customizable and which can be hard coded with fixed values. The same idea can be applied to other IlvGraphic subclasses as well. JViews has plenty of features in general purpose IlvGraphic subclasses, but when memory is critical and the purpose is more special and less general, optimizing graphic classes might be worth the effort.

In order to stimulate new research in graph layout algorithms, a contest is organized in conjunction with the GD’2008 conference. The topologies of several graphs from real world applications are given, and the goal is to create the best (aesthetically or, for the application domain, the most suitable) drawing of the graph by using state of the art or new innovative graph layout algorithms. Additionally, an online contest similar to a programming contest is held, where a difficult problem must be solved online within 1 hour. The details of the contest can be found at http://www.graphdrawing.de/contest2008/.

I have the pleasure to be a member of the contest committee this year, and I am excited to soon see the result of these difficult graphs at the conference. If you are a JViews customer, most likely you are already using our graph layout algorithms. You can try the contest graphs and you will see why they are so difficult to lay out. But who knows, maybe you also know how to solve the challenge, and maybe you will be the next winner of the Graph Drawing Competition. Then the honor will be all yours!

You can watch a movie here of the resulting applications.

This movie is best viewed in full screen mode:

ILOG JViews tries to fill this gap, bringing rich graphical displays to Eclipse RCP. We do this in two different ways: by offering an enhanced bridge that lets you mix AWT and SWT, and also by adding professional-grade diagramming services to SWT.

In this 40 minute presentation, ILOG JViews Product Manager Jerome Joubert describes these two approaches and illustrates them with a number of demos. If you are using Eclipse RCP and you need highly-graphical displays, then you may find this presentation of interest.

The following movie is best viewed in full screen mode:

Originally presented in May, 2008 by Jerome Joubert.

The following movie is best viewed in full screen mode:

Originally presented in February,2008 by Hariharan Subramanian of Sabre.

This presentation is essentially geared to people already familiar with O.R., explaining how they can make their projects more successful by adding displays that present their results in a meaningful way.  Here’s what their abstract says:

One of the most common problems facing optimization applications is that key decision makers do not always understand the formulations and solutions created by O.R. professionals. Most O.R. applications offer only static interfaces with pages of tabular data. If the decision makers using your applications lack understanding of the solution, then they are unlikely to continue using it.

So have a look at this 10 minute presentation, rich with plenty of real-world examples.  Maybe there is something applicable to your domain…

The following movie is best viewed in full screen mode:

Originally presented on May 22,2008 by Dan Jeffrey and Irv Lustig.

Referencing a user-defined property within the right hand value expressions of a CSS declaration is fairly straightforward. For example, let us say that you want to fill an activity bar with a color defined as an attribute of the activity itself. In this case, you have a data model that contains activities that have a “bg” property, where the values are HTML rgb color encodings or the names of standard SVG colors. You can then use a declaration like this in your CSS stylesheet to color an activity graphic with the color specified by the activity’s property:

activity[bg] {
  background: @bg;
}

Notice the reference to the bg property in the rule selector expression as well. This ensures that the rule’s declaration is only evaluated if the bg property is non-null. Subsequently, if you have code that modifies the activity’s bg property, the activity will be updated with the new fill color:

anActivity.setProperty("bg", "orchid");

Referencing user-defined properties within a CSS rule selector can provide more power than the simple test for a non-null value that I showed in the previous example. Let us imagine that you want to customize the CSS styling of an activity based upon whether it is currently displayed expanded or collapsed in the Gantt chart. In fact, this was a recent request from one of our customers. At first glance, it appears that there might be several ways that you could write a rule selector that will evaluate whether an activity is expanded or collapsed. First is the usage of CSS pseudo-classes. For example, one could imagine to write a set of rules like this:

// This is the default rule for collapsed activities
activity {
  font: arial,plain,10;
}

// Rule for activities with expanded pseudo-class
activity:expanded {
  font: arial,bold,12;
}

Unfortunately, the set of activity pseudo-classes is fixed to the following: parent, leaf, milestone, and selected. Therefore, using pseudo-classes will not work for our needs. The second possibility is to use a user-defined property of the activity to store it’s expanded state. For example, code such as:

anActivity.setProperty("expanded", true);

would flag the activity as being expanded. Then, it is a simple matter to change the selector of the second rule above to this:

// Rule for activities with expanded property set true
activity[expanded = true] {
  font: arial,bold,12;
}

The second part of this equation is to write some code that will update the expanded property of activities as they are expanded and collapsed in the Gantt chart. To do this, you will want to register an instance of the following class as a VerticalExpansionListener on the chart.

class ExpansionHandler implements VerticalExpansionListener {
  public void updateActivity(IlvActivity activity, boolean expanded) {
    if (!(activity instanceof IlvUserPropertyHolder)) {
      return;
    }
    ((IlvUserPropertyHolder) activity).setProperty("expanded", expanded);
  }

  public void rowExpanded(RowExpandedEvent event) {
    IlvHierarchyNode[] expanded = event.getExpandedNodes();
    for (IlvHierarchyNode activity : expanded) {
      updateActivity((IlvActivity) activity, true);
    }
  }

  public void rowCollapsed(RowCollapsedEvent event) {
    IlvActivity activity = (IlvActivity) event.getCollapsedNode();
    updateActivity(activity, false);
  }

  public void rowsInserted(RowsInsertedEvent event) {}
  public void rowsRemoved(RowsRemovedEvent event) {}
  public void rowMoved(RowMovedEvent event) {}
  public void rowHeightChanged(RowHeightChangedEvent event) {}
}

Note, that for a complete implementation you will also need to handle the rowsInserted, rowsRemoved, and rowMoved events. This is because when the first child is inserted under an activity, the former leaf activity becomes an expanded parent. Conversely, when the last child is removed from an expanded parent, the former parent activity becomes a non-expanded leaf. I will show how to implement the remaining ExpansionHandler methods in my next post on this topic.

First up: the health of the show 

We product marketing guys can use the JavaOne show as a quickie litmus test to gauge the general health of the Java marketplace.  How is the show going, compared to last year and the year before?  Is JavaOne still, after 10+ years, an important event?  Are there lots of attendees and other vendors?  Is Java itself still important?   After all, if there is a big downturn or upswing, we may use this to help us determine the resources we dedicate to our Java product line.

Diagnosis:  Steady, with just a slight decline in the number of sessions, events, people, and general buzz.

Next up:  How is the exhibit booth?

This is something that many conference attendees never pay attention to: they are there to soak up knowledge and couldn’t care less about commercial vendors and their exhibit booths.  But, of course, we vendors care very much about things like booth traffic (are we on the main drag, or in no-man’s land?), booth placement (do we have noisy neighbors with annoyingly amplified sales pitches?), booth messaging (will the guy walking by understand what we do quickly or is our signage too obscure?), booth giveaways (is that guy who is collecting the free goodies–a.k.a. a “trick or treater”–really a possible customer?), etc.    Which of our competitors are there at JavaOne this year?  What are they pushing that’s new?  And, more intriguing, which competitors are not there?   It all has a sort of (upscale) “carnival midway” feeling about it…

Diagnosis:  Very healthy (for us, at least).  Those who worked in the ILOG booth were quite pleased with the large number of conference attendees they chatted with. 

Finally: What’s the buzz?

As a product manager, I look around the show floor to see if I’m missing any trends that might effect the products I work on.  Likewise, it’s interesting to see what “buzz” Sun is putting out there, to show that they understand the trends and are, of course, leading the way.  (wink!)

This year, in the Java circles that we run in (user interfaces, of course), the hands-down hot topic was RIA (Rich Internet Applications).  Last year, Sun announced JavaFX and this year they seemed to re-announce it.   JavaFX is their answer to Adobe’s Flex and AIR, and to Microsoft’s Silverlight (both of whom were also at the conference, interestingly enough).   Most of the people I spoke with said they have a “wait and see” attidtude about JavaFX, though.

JavaFX, Flex, and Silverlight are all trying to do the same thing: give the world a RIA experience that is far better than Ajax.   Ajax and its programming frameworks are a beast, developers tell me, and the end result of all that hard work is, of course, quite cool–but it’s not as interactive or as glitzy as JavaFX, Flex, or Silverlight.

Diagnosis:  For RIA, the fight for the developer mind is still on.  For us at ILOG, we are actively following Flex/AIR (see our ILOG Elixir product) and are experimenting with Silverlight.   Of course, Ajax has been a big part of all of ILOG Java products for some time now, and will continue to be a major emphasis for us.   So, for us, the buzz at this show was all about RIA and we were smack dab in the middle of it.

A final note:   A big thank you to all of the ILOG customers who came by the ILOG booth to chat with us.   It’s nice to hear about your successes.   And we heard you about some of the Ajax interoperability issues you might face soon, and have started burning the midnight oil…