Thanks for reporting this problem. I plan to implement changes that will better
integrate canvas in the near future, and I'll be sure that those changes fix this
problem, too.

You could workaround it by drawing the gridlines with LINE_CANVAS curves too
(tedious, I know, but it could work if you really needed the gridlines to be behind
the curves.

The fact that you may not be able to properly control z-order for LINE_CANVAS is
documented in the LINE_CANVAS javadocs, at least (though not this particular
grid-line problem).

John

(No comment was entered for this change.)

In addition to generating the gridlines via a series of LINE_CANVAS curves, there are
a couple of other possible workarounds (have not tried these, but no logical reason
why they should not work):

o You could use setBackgroundImageURL and create a background image that contained
the gridlines, rather than letting GChart generate them. This assumes that the "graph
paper" on which your chart is placed is static.

o You could generate a "spark-line-like" GChart and place it into an annotation via
setAnnotationWidget using the  ANCHOR_NORTHWEST annotation location on an empty chart
that had the gridlines on it (this should work because annotations are always placed
on top of everything else--its a sort of "chart on top of a chart" approach).

o You could edit the GChart.java code lines that add(canvasPanel, 0, 0) so that this
addition is made after add(imagePanel, 0, 0) instead of before it. This will
short-circuit your hover feedback, though, but it might be the easiest solution if
you don't care about hover feedback or are not using it anyway.

o You could simply use a line curve with a width (setBorderWidth) that was thicker
than the gridlines. That way, the gridline would never entirely occlude the line
curve. Though not a perfect solution, it solves the main problem if you have a curve
that exactly overlays a gridline.

Basically, the problem with the current canvas implementation is that all canvas
curves are placed onto a single canvas, and all HTML elements are placed onto a
separate panel (a sibling of that canvas). The gridlines are on the element panel,
which is positioned on top of the canvas panel (the other way around zaps element
based, setTitle, hovertext, so I chose the lesser evil). The way I'm now planning to
fix this problem is that, whenever an external canvas is plugged into GChart, GChart
will just use canvas for everything, automatically. But to do that and not lose my
hover feedback (since that is element, setTitle based right now) I have to upgrade
hover feedback first. Hence this problem is pushed back to 2.5 since hover feedback
improvements (2.4) must happen first. 

Thanks for the suggestions on workarounds.  I will probably just use 2 pixel lines
even though they tend to "blur" the chart when there are a lot of up/down jaggies.  I
might also look at the change to the add() order since I don't really need hovers.

Opps.  A 2-pixel line still does not display when the Y value is the same as the
maximum of the chart - e.g. the top horizontal grid line still hides it.  I may have
to adjust the max Y axis to be the max value plus 1 instead of letting it auto-scale
(actually it would be nice if auto-scaling left a bit of room at the top of the
chart, it looks odd for the chart lines to hit the top edge).

Don't understand why 2-pixel lines are occluded at top line since gridlines are
supposed to be 1-pixel, but 3-pixel lines might work if its some kind of roundoff
effect. 

You can use getYAxis().getDataMax() to easily get the data-determined maximum for
your adding 1 approach.

I like the idea of a little extra space at the top (or bottom, left, right) but I'm
not sure exactly the best way to determine how much, or to allow the user to specify
that space.

How do you feel about methods that complement existing setAxisMin and setAxisMax, say:

  getYAxis().setAxisMaxMargin(double extraPaddingAtTop)
  getYAxis().setAxisMinMargin(double extraPaddingAtBottom)
  getXAxis().setAxisMaxMargin(double extraPaddingAtRight)
  getXAxis().setAxisMinMargin(double extraPaddingAtLeft)
  etc.

These would add the specified padding to the getAxisMax or getAxisMin values, which
would still be dynamically data-determined (or explicitly set) exactly as now.
Setting these marginal increase values to 0 would produce the current behavior. Since
your goal is a little extra graphical space, perhaps the margins should be expressed
as a percentage of the full model unit min to max range over the axis? 

Worth adding something along these lines? Interested to hear what you think. Thanks
for the suggestion.

John

GChart 2.5 corrects this problem. See the 2.5 release notes for further information.