Update backend_cairo.py

[eeyrjmr]

Commenting out explicit point check w.r.t. cairo backend. Does not seem relevant with newer Cairo
reference: matplotlib.1069221.n5.nabble.com/Matplotlib-py3-gtk3-td42953.html

[tacaswell]

If you are going to take the lines out, just remove them. Version control will take care of the history for us.

[tacaswell]

Other than the minor point of just deleting the lines, this looks good to me. @mdboom Who is the cairo expert?

[mdboom]

It would be nice, but not required, to determine when this limitation was removed from Cairo and only remove the check for those versions. If that's easy to great, otherwise, let's not let this hold us up. The Cairo changelog doesn't seem to mention anything.

[tacaswell]

@eeyrjmr Could you add a CHANGLOG entry for this change?

[eeyrjmr]

@tacaswell ok

[eeyrjmr]

It might not be without problems though.... While plotting > 18980 does not result in some crash (of python), it might be responsible for some serious UI slowdown due to pyGObject+cairo+matplotlib.

[tacaswell]

@eeyrjmr This also needs to be re-based. I suspect the conflict is in the changelog.

[eeyrjmr]

Looking a bit more into this I don't think it is wise to apply this patch, in fact Cairo's present state does bring into question pyGObject with matplotlib... There are bigger problems with cairo than 18980 points...

pyGObject fully converted over to cairo (gtk2 iirc used gdk to draw) and it is dog slow... REALLY painfully slow...
I use an embeded matplotlib to plot data captured from a piece of custom hardware. My testcode plots a perfect sinus to test stuff and that is fine. 30,000 datapoints and actual data and it grinds to a halt (5sec ui lag...).
EVEN 10,000 points (note has to be noisy as mpl does some interpolating: TIME = np.arange(0,2_np.pi,2_np.pi/30000); VOLT1 = np.sin(TIME + 0_(2_np.pi/7))+ np.random.rand(30000) ) causes serious ui lag.

I am about 20% into a pyQT4 conversion.

[tacaswell]

de-milestoning and closing.