The above methods let you precisely control the amount of space taken up by chart decorations (title, footnotes, axis labels, and legend key) and, thus, the exact pixel size of the chart as a whole.
In particular, Sparkline charts (those without any decorative elements or spacing whatsoever) are straightforward with this release, as illustrated by this new example chart.
Previously, the table-based widgets (DockPanel, Grid) that GChart used to place these decorations around the main plot area varied (as expected with HTML tables) in size and placement from browser to browser. This (in hindsight, poor) original implementation choice made precise browser-independent chart sizing tedious, if not impossible.
Though this is a big improvement, it is a potentially breaking change since the decoration placement algorithm is completely different in v2.2. I've tried to adjust the defaults and such so that, if your pages are relatively flexible with regard to chart size, you should usually be OK, but if you've carefully tweaked your charts to make them fit just perfectly within their host page, you'll likely have to tweak them again using the above methods. Don't let that keep you from upgrading, though: these changes greatly simplify producing chart sizes and decoration placements that are exactly the same across all browsers--so you'll finally be able to get it right this time.
Regarding that new decoration layout algorithm, here it is in a nutshell:
This new example code uses the LINE symbol type to produce a simple "x2 vs x" line chart.
This new LINE symbol type draws connected lines more efficiently by using a series of vertical or horizontal line segments (previously, you had to use BOX_CENTER with a 1px fill spacing, which rendered the line with a series of single pixel "dots").
With this new LINE symbol type, curve HTML element counts, and hence chart update times, are (for a chart whose x-value sequence is non-decreasing) proportional to (in the worst case) the width of the chart rather than (as with the previous version) the pixel length of the curve. For certain curve data (e.g. a triangle wave with sharp peaks, a square wave, etc.) order of magnitude speedups are possible. But, for more typical curve data (e.g. lots of close-to-45-degree-angled connecting lines) you can expect only modest performance improvements.
Due to Client-side GChart's reliance on rectangular rendering elements, line charts are still not its forte (that would be bar charts). So, even with these improvements, for many line chart applications, you'll have to settle for only two (you can let the user choose which two) of the following three desirable features:
The updated live demo contains a new SymbolType.LINE example chart at the bottom of the page that has a button on it that lets you toggle between the three possible pairs of these desirable features to show the exact same (sine and cosine) data set using:
Unless your visitors all have client environments much faster than mine, the one option you really want: large size, high resolution, fast updating, still isn't available for line charts. So, it's important to play with this demo GChart in your typical client environments to get a feel for if a line chart with an acceptable combination of size, update speed, and resolution is achievable for your application.
Finally, don't forget that for many applications, a more efficient, "rectangle-friendly", GChart, such as a scatter plot, bar chart, or a line chart with (widely spaced) dotted connecting lines, can be an acceptable alternative to a solidly connected line chart.
If you use one of these types, the actual x,y position of your point is ignored: the point is instead always placed in the northwest, north, northeast, etc. position within the plot area.
Typically, you'd add a point to a curve whose symbol employed one of these new types, and then you'd use the Point class methods setAnnotationWidget, setAnnotationLocation , setAnnotationXShift , and setAnnotationYShift to position an externally created widget (say, a Grid to add a table) relative to the associated "anchoring" compass point position.
These are the same symbol types used internally by the new decoration placement algorithm; use them whenever you need to precisely position your own "decorative" widgets relative to the corners, edges, or center of the plot area.
The addPoint, setX and setY methods now interprete -Double.MAX_VALUE as a special keyword that means "the smallest x or y model coordinate value visible on the plot area" and +Double.MAX_VALUE to mean "the largest x or y model coordinate value visible on the plot area".
You can use these special "keyword values" whenever you want to position something along the top, right, bottom, or left edges of the plot area.
Previously, if you used a dynamically determined axis limit (by setting the axis min or max to Double.NaN) it forced a redraw of the associated axis, tick marks, and tick labels, even if they did not change.
In 2.2, a redraw is only forced if the dynamically determined axis limits actually change between updates.
If passed false, anything drawn outside of the chart as a whole (including decorations) will be clipped off. The default is true.
Note that this new method differs from the earlier setShowOffChartPoints, which determines if points that fall outside of the (smaller) plot area within the chart are drawn or not.
Previously, vertical bars only aligned perfectly with their corresponding gridlines along their top and bottom edges, and horizontal bars only aligned with their corresponding gridlines along their left and right edges. Alignment of other edges could vary depending on roundoff errors.
As of GChart 2.2, these symbols align with their corresponding gridlines on all four edges. This change makes it easier to build charts with adjacent, interlocking, vertical or horizontal bars, without annoying, 1px, round-off-induced gaps. However, this is a potentially breaking change. Specifically, due to these changes, vertical bars get their left and right edges (and horizontal bars there top and bottom edges) pushed out and extra half pixel. If the resulting new look is unacceptable to you, try decreasing the width of vertical bars, or the height of horizontal bars, by 1px.