Jin-chung> When I do the following, the plot is doing something
Jin-chung> weird. It fills up a triangle area between first and
Jin-chung> second points, after the axis command:
>>>> n = 5000.0 plot([n,-49.9,-49.9,-49.99,-50,-50])
>>>> axis([0,5,-50.1,-50+0.1])
Jin-chung> This only happens at a very narrow window of boundary
Jin-chung> conditions. If n is smaller (e.g. 4000) or if Y range
Jin-chung> is larger (e.g. set the min at -50.2 instead of -50.1),
Jin-chung> it becomes normal.
Many months ago Srinath Avadhanula reported the same bug - strange and
unexplained filling behavior with very narrow axis limits and a points
far outside those limits.
http://sourceforge.net/mailarchive/message.php?msg_id=7973663
As I wrote then, I think the root of this bug is that matplotlib is
doing the transforms in the front end and passing the backend display
coordinates. In some cases, you can get very odd display coordinates,
eg very large positive or negative numbers, and I think this is what
is causing agg to fail (I know agg has some canvas size limitations,
something like 4096x4096 pixels if memory serves). For some time I've
been wanting to refactor the backend code to pass data + transform to
the backend rather than transformed data. This would fix a lot of
little bugs, eg some subpixel artifacts in agg that I've had to hack
around by special casing, and would improve performance on some
backends, like PS and SVG where you can simply provide the data
coordinates and the vec 6 affine and let the display device handle the
transformations.
It's a fairly big change, and requires some thought as to how to do it
right in the presence of nonlinear/nonseparable transformations, but
it's on the list.
I see you are actively working to maintain your role as the finder of
the toughest bugs. Unfortunately, Srinath scooped you on this one.
Thanks for reminding me that it is still a problem, as I had allowed
it to slip to the most distant reaches of my conciousness.
JDH