From kivy-garden/garden.matplotlib#35 it looks like this only happens with the kivy backend which is not maintained by mpl.

By 'from source' do you mean current master? Can you try from the 1.5.x branch? Can you do some bisecting to sort out what changed?

Given that this works with kivyagg I strongly suspect that the issue is in the kivy renderer. We did recently make some changes to how clipping is done and I recall some other issues with kivy + clipping.

Hi, yes it happens with the non Agg backends, seems something to be broken on the draw path. I did not check in detail though but I'll print what is being received as a path and post it later on because I suspect it could be the convert to polygon function. I tested with 1.4.3 (OK) , 1.5.x (fail) , current master (fail). Gtk backend has the same issue but I think you are not giving support to that anymore I recall. The clipping is fixed I tested it with both 1.5.x and current master. I suspect you are sending a wider area now ?

I went through this a bit with the Kivy backend, and found that Path.to_polygons() seems to be clipping any paths of length 2 (and sometimes length 3, if there's a 0.0 as one of the coordinates):

Path(array([[ 0.5,  0. ],
            [ 0.5,  1. ]]), None) , color None , width 1100.0 , height 794.528043776  => []

I noticed, for example, if I specified numpoints=2 when drawing a legend with matplotlib.pyplot.legend, no lines were drawn, but if I said numpoints=3, a line was drawn.

I gather this needs to be addressed by the kivy maintainers, so I am closing it. Reopen it if this is incorrect.

The problem is with Path.to_polygons(). That's matplotlib, not Kivy. Please reopen (and fix!).

@janssen In your comment above you seem to state that this is a bug in the Kivy backend. Is that not the case? The Kivy backend is not in matplotlib but maintained externally

With mpl v2.x, looks OK to me:

In [1]: import numpy as np
In [2]: from matplotlib.path import Path
In [4]: p = Path(np.array([[ 0.5,  0. ],
            [ 0.5,  1. ]]), None)
In [5]: p.to_polygons()
[array([[ 0.5,  0. ],
        [ 0.5,  1. ]])]

I get the same (correct) result with mpl v1.5.1. If you are not getting this result with your Kivy backend, then presumably either it is some other version, or the backend is overriding Path.to_polygons()

p = Path(numpy.array([[ 0.5,  0. ], [ 0.5,  1. ]]), None)
>>> p.to_polygons(width=1.0, height=1.0)
[]
>>> 

Am I simply confused about what 'width' and 'height' should be?

No, I didn't see the importance of width and height until I saw this example. I don't think this has anything to do with whether there is a zero in the array, though:

In [18]: Path(numpy.array([[ 0.5,  0.5], [1, 1]]), None).to_polygons(width=100, height=100)
[]

Attn: @mdboom

The problem is that you can not make a closed polygon from two points.

In [9]: p = Path(np.array([[ 0.5,  .1], [ 0.5,  1. ], [2, 2]]), None)

In [10]: p
Out[10]: 
Path(array([[ 0.5,  0.1],
       [ 0.5,  1. ],
       [ 2. ,  2. ]]), None)

In [11]: p.to_polygons(height=5, width=5)
Out[11]: 
[array([[ 0.5,  0.1],
        [ 0.5,  1. ],
        [ 2. ,  2. ],
        [ 0.5,  0.1]])]

The bug might be that the non-clipped case returns a non-polygon.

On 2016/07/15 8:41 PM, Thomas A Caswell wrote:

The problem is that you can not make a closed polygon from two points.

I don't see this as the fundamental problem here; to_polygons will
happily make a polygon out of 3 co-linear points, tacking a copy of the
first point on to the end to close it. Why shouldn't it return a result
from 2 points with the first repeated as the third?

Clipping enters in because it triggers a completely different code path,
through the extension module.

I gather this to_polygons method is being used for paths that are not
polygons at all--that is, grid lines--so maybe the problem is that some
other method should be used for extracting a line from a Path.

I'm looking into this now...

So, this change came out of #5670, fixed in #5672.

The issue here is that there are some users that rely on to_polygons to return only polygons because they do further processing on the data. The fact that it worked for kivy's needs on 2-element polylines as well was just an accident prior to #5670 being fixed.

It seems impossible to fix this bug to meet both use cases, so I've added a flag "closed_only" that when True will only return closed polygons, throwing out any 2-vertex polylines. Passing False should give the behavior kivy wants where to_polygons will emit both polygons and polylines.

So the fix involves both merging #6756 on the matplotlib side and kivy updating to pass closed_only=False to to_polygons on their side (and the appropriate version check to continue to support earlier versions of matplotlib).

I'll get the Kivy side updated. What version of matplotlib might this land in? I think Kivy will just have to add prereqs to refuse to use intermediate versions (between 1.4 and whatever version this lands in).

It will be in 2.0.

I guess the GDK backend needs a similar change but It might not be worth it given that we have deprecated it?

So, I've tried installing 2.0.0rc1, changing all the Kivy to_polygon() calls to add "closed_only=False", and we still have the same problem.

Whoops, no, I take it back. I still had my changes in there which were preventing me from seeing it. I think we're good.

@janssen Great to hear!

Unfortunately, I just got around to testing on Windows. This bug still persists on Windows. We are now getting the gridlines on Linux (with matplotlib 2.0.0, Ubuntu 16.04, Anaconda Python 2.7.13) but not on Windows (Windows 10, Anaconda Python 2.7.13).

That is very odd that it is OS dependent. My (biased) guess is that the issue is in kivy.

How could we test that? I've tried switching to the Kivy Agg-based version, and that works fine. And the Kivy drawing backend works fine on Linux.

Another possibility is Visual C versus gcc, I guess. I compiled matplotlib with the Visual C++ for Python package, using a Windows 7 machine. Where precisely is the C++ code that does the to_polygons() manipulation, if you know?

Ah, found this. Now works on Windows, too. Sure enough, it was a misapprehension in my code.

@janssen Sorry, did not see your comment from 9 days ago.

What was the problem?