For additional information about Client-side GChart performance, see Tips For Making Client-side GChart 2.1 Updates Faster.
The original addTick method now lets you use HTML and even
GWT Widgets to define the tick label. Want clickable tick
labels? Just pass in a Button instead of a String.
Why should tick labels have all the fun? Want to make something
happen when they mouse over a point? Just add a Widget
that sources mouse events (e.g., via new
Image("clear.cache.gif")) as that point's annotation, center
it over the point with
setAnnotationLocation(AnnotationLocation.CENTER), and
attach an appropriate MouseListener.
This new method lets you have gridlines on every other tick if you want, or every third tick, etc.
The first method lets you use a custom image to define the rendered symbols on a curve.
Similarly, the second method lets you define a custom image for the
plot area's background (the plot area is that rectangular region,
bordered by x and y axes, where your curves are rendered).
By default, if GChart has leftover Widgets from the previous update it no longer needs to render your chart, it holds onto them in the expectation that they may be needed in some future chart update. That can be faster.
Pass true to this method, though, and GChart immediately frees up any such unused Widgets. That can be slower, but it can also save memory.
To simplify the creation of annotation-only curves, this new symbol type, which does not display any symbol at all, was added.
When I compiled my old test set with GChart 2.1, there were only one or two trivial changes I needed to make to get it to run. With luck, your application will work completely without incident. But if it doesn't "just work", to the best of my knowledge, it will be due to one of the easily-worked-around incompatibilities listed below:
I found while implementing the performance improvements, it would be very convenient if each point knew what curve it was on. So I made Point an inner class of Curve. It seemed like a good idea at the time.
What I overlooked was that anyone that had some lines of code such as:
GChart.Point p = getCurve(0).getPoint(0);
p.setAnnotationText("I am point 0 of curve 0. I am number one!");
Will now need to replace them with:
GChart.Curve.Point p = getCurve(0).getPoint(0);
p.setAnnotationText("I am point 0 of curve 0. I am number one!");
I considered adding an explicit parent curve reference and reverting back to GChart.Point so you would not have to do this, but since points cannot ever exist independent of their associated curve, I decided to stick with GChart.Curve.Point.
These were deprecated in 2.0 and were removed in 2.1 to simplify and speed up the hovertext processing.
Workaround: In the String argument passed to
Symbol.setHovertextTemplate, replace each XXX with
${x} and each YYY with ${y}.
To make chart updates faster, GChart needs to keep track of what changed and what didn't and that requires an extra int, String reference, etc. per element/attribute tracked. The test set takes up less than 1MB per chart, on average, so I don't expect this to be a significant issue for most applications, which will likely run short on time long before they run short on memory. To get a sense of how much memory a 500 point GChart uses, open up Windows Task Manager (or the Mac or linux equivalent thereof) before you visit the GChart live demo.
If you use an image URL on one of your charts, you may have to prefetch it yourself. Auto-prefetching sounds nice, but I've read incorrect use of Image.prefetch can cause memory leaks so I didn't want to automatically do something that might do that. Besides, prefetching is one of those things you should do when a page first loads, and since you can change GChart's image URLs at any time, it's impossible for GChart to know what images it may need to prefetch at that time.
If an image GChart uses (that would be either the default gchart.gif or an image you passed into GChart's setBlankImageURL, setImageURL, or setPlotAreaImageURL methods) isn't coming up as smoothly as you'd like it to, consider issuing an Image.prefetch on the image in question when your application first loads into the page.
The algorithm is just a little bit better. If the new positions bother you, use setAnnotationXShift and setAnnotationYShift to tweak them back to where you think they should be.
As of 2.1, hovertext isn't actually added until the mouse hovers over the HTML element in question. In previous versions, the setTitle method was called at chart update time, regardless of if any hovering was ever done. The new method speeds updates, since formatting the numbers in the hovertext is surprisingly expensive.
However, on pages so busy (or in browsers so inept--I'm talking about you, IE6) that the browser has trouble figuring out exactly what the mouse is hovering over, your hovertext might appear to disappear (it's actually just very slow in coming up). If your page is that busy, disappearing hovertext is probably the least of your worries.
Past versions incorrectly included invisible curves in determining the min/max data points for defining auto-computed axis limits (when min or max are Double.NaN). This version excludes those hidden curves from such calculations, which means that auto-determined axis limits could be narrower if you used setVisible(false) on any of your curves.
If your application relied on the old behavior, the easiest fix is to explicitly define the axis min and max to whatever you think is appropriate.