John Hunter wrote: >>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes: > > > Charlie> This might not be related, but since when did bar charts > Charlie> of zero break? > > Charlie> bar(arange(10), zeros(10)) > > I think this is related to Eric's MaxNLocator support code. Correct. I found and fixed one clear bug, but now it is tripping somewhere else. I'll track it down. Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Correct. I found and fixed one clear bug, but now it is Eric> tripping somewhere else. I'll track it down. It would be nice to collect these torture test scripts in a subdir of unit with a torture_driver routine. More poorman's unit testing.... Charlie, feel free to contribute your zeros bar as exhibit A. JDH
John Hunter wrote: >>>>>>"Eric" == Eric Firing <ef...@ha...> writes: > > > Eric> Correct. I found and fixed one clear bug, but now it is > Eric> tripping somewhere else. I'll track it down. > > It would be nice to collect these torture test scripts in a subdir of > unit with a torture_driver routine. More poorman's unit testing.... > > Charlie, feel free to contribute your zeros bar as exhibit A. Good idea. I found and fixed the second bug (what a difference "<" vs "<=" can make!) and svn now passes this test. Eric
I'm having second thoughts about the wisdom of having postscript handle the transforms. With the new API, I run backend_driver.py and get a file called axes_demo_PS.ps. On my machine, it takes about 10 seconds to open this file if it was created with the new API. If I mask draw_markers and recreate the postscript file, it loads instantly. Any thoughts?
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> I'm having second thoughts about the wisdom of having Darren> postscript handle the transforms. With the new API, I run Darren> backend_driver.py and get a file called Darren> axes_demo_PS.ps. On my machine, it takes about 10 seconds Darren> to open this file if it was created with the new API. If I Darren> mask draw_markers and recreate the postscript file, it Darren> loads instantly. So you think the performance hit is caused by gs (or whatever viewer you are using) by the postscript engine doing the transformations? It surprises me that this would be so inefficient. We have the option of doing the transformations in the ps backend... JDH
On Monday 03 April 2006 11:00, Darren Dale wrote: > I'm having second thoughts about the wisdom of having postscript handle the > transforms. With the new API, I run backend_driver.py and get a file called > axes_demo_PS.ps. On my machine, it takes about 10 seconds to open this file > if it was created with the new API. If I mask draw_markers and recreate the > postscript file, it loads instantly. > > Any thoughts? Let me make a correction. Viewing the file should not take so long, but there is something strange going on that I dont understand. axes_demo_PS.ps actually takes almost a full minute to load on my computer if the new API is used (excuse my first incorrect report). What I see is that the blue line is immediately rendered, and then ghostscript seems to stall for 45 seconds, and then renders the rest of the file. If I comment out the blue line in the postscript file itself: % gsave % 446.4 345.6 72 43.2 clipbox % [446.4 0 0 6920.64 72 159.326] concat % 0 0.001725 m [...] % 9.999 -4.733e-05 l % gsave 0.00224014 0.000144495 scale stroke grestore % grestore then the file will load immediately, with no pause. This is strange, I cant identify the source of the hangup. Darren
On Monday 03 April 2006 11:16 am, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> I'm having second thoughts about the wisdom of having > Darren> postscript handle the transforms. With the new API, I run > Darren> backend_driver.py and get a file called > Darren> axes_demo_PS.ps. On my machine, it takes about 10 seconds > Darren> to open this file if it was created with the new API. If I > Darren> mask draw_markers and recreate the postscript file, it > Darren> loads instantly. > > So you think the performance hit is caused by gs (or whatever viewer > you are using) by the postscript engine doing the transformations? It > surprises me that this would be so inefficient. > > We have the option of doing the transformations in the ps backend... I think there are two issues here. The postscript interpreter doesnt like to stroke long paths. If I break the path into 50 point chunks instead of 1000 point chunks, I see an improvement. Also, if I do the transform in backend_ps, instead of passing it to the postscript interpreter, I see a big speedup at render time. Right now I am doing this transform by hand: a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y = xo,yo Is there a better way to do this? I thought I could simply call numerix_x_y, but that function is not compatible with nonlinear transforms (returns a domain error if one of the axes is log-scaled). Thanks, Darren
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> I think there are two issues here. The postscript Darren> interpreter doesnt like to stroke long paths. If I break Darren> the path into 50 point chunks instead of 1000 point Darren> chunks, I see an improvement. That's odd, because we never saw an issue stroking long pats before. Or at least noone has ever reported it. Darren> Also, if I do the transform in backend_ps, instead of Darren> passing it to the postscript interpreter, I see a big Darren> speedup at render time. Right now I am doing this Darren> transform by hand: Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y Darren> = xo,yo Darren> Is there a better way to do this? I thought I could simply Darren> call numerix_x_y, but that function is not compatible with Darren> nonlinear transforms (returns a domain error if one of the Darren> axes is log-scaled). You can transform the xy values point by point. Instead of separating them into their nonlinear and affine components as we are currently doing in backend_ps, you can call trans.xy_tup which will do both. If successful, it will return the transformed xy, if it fails, it will raise a ValueError, and you can set the moveto/lineto state accordingly. But I am still confused by your previous post: you said that when you tried to load the simple plot example PS file in gs, the line rendered quickly, and then there was the interminable pause. This suggests that it is not the transformation in gs that is the bottleneck, but something that happens after it. In any case, here is an example script creating a semilogx transform. The first transformation succeeds, the second raises a ValueError from matplotlib.transforms import SeparableTransformation, \ Point, Value, Bbox, LOG10, IDENTITY, Func import matplotlib.numerix as nx # make some random bbox transforms def rand_point(): x,y = nx.mlab.rand(2) return Point( Value(x), Value(y) ) def rand_bbox(): ll = rand_point() ur = rand_point() return Bbox(ll, ur) b1 = rand_bbox() b2 = rand_bbox() funcx = Func(LOG10) funcy = Func(IDENTITY) # semilogx trans = SeparableTransformation(b1, b2, funcx, funcy) print trans.xy_tup((1,2)) #ok print trans.xy_tup((-1,2)) #raises
Hi John,
On Monday 03 April 2006 10:16 pm, you wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I think there are two issues here. The postscript
> Darren> interpreter doesnt like to stroke long paths. If I break
> Darren> the path into 50 point chunks instead of 1000 point
> Darren> chunks, I see an improvement.
>
> That's odd, because we never saw an issue stroking long pats before.
> Or at least noone has ever reported it.
I suppose it could be an issue with my gs, a few weeks ago I upgraded to
gcc-4.1 and have since recompiled gs. Would you run this script:
from pylab import *
x=rand(1000)
y=rand(1000)
plot(x,y)
savefig('apitest.eps')
and then open the file in ggv? If it opens quickly, maybe you could also try
rand(10000).
> Darren> Also, if I do the transform in backend_ps, instead of
> Darren> passing it to the postscript interpreter, I see a big
> Darren> speedup at render time. Right now I am doing this
> Darren> transform by hand:
>
> Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y
> Darren> = xo,yo
>
> Darren> Is there a better way to do this? I thought I could simply
> Darren> call numerix_x_y, but that function is not compatible with
> Darren> nonlinear transforms (returns a domain error if one of the
> Darren> axes is log-scaled).
>
> You can transform the xy values point by point. Instead of separating
> them into their nonlinear and affine components as we are currently
> doing in backend_ps, you can call trans.xy_tup which will do both. If
> successful, it will return the transformed xy, if it fails, it will
> raise a ValueError, and you can set the moveto/lineto state
> accordingly.
I see. But can that be done in a list comprehension? I think it will require a
regular for loop. I think doing the transforms as I described above is a
better solution. It fixed the render times on my machine and my
backend_driver tests looked fine. I'll wait for feedback, and test a little
more tomorrow before committing.
> But I am still confused by your previous post: you said that when you
> tried to load the simple plot example PS file in gs, the line rendered
> quickly, and then there was the interminable pause. This suggests
> that it is not the transformation in gs that is the bottleneck, but
> something that happens after it.
It was axes_demo.py. I discovered the reason: a 10,000 pt line is written to
the postscript file, but only 1000 points are drawn because of the x-axis
limits. So it was churning away, processing points that dont get drawn. I
confirmed this was the case: by commenting out the other 9000 points in
axes_demo_PS.ps, the render time improved.
Darren
Darren,
> I suppose it could be an issue with my gs, a few weeks ago I upgraded to
> gcc-4.1 and have since recompiled gs. Would you run this script:
>
> from pylab import *
> x=rand(1000)
> y=rand(1000)
> plot(x,y)
> savefig('apitest.eps')
>
> and then open the file in ggv? If it opens quickly, maybe you could also try
> rand(10000).
About 25 seconds on a 1.6G Pentium M, ESP Ghostscript 8.15.1 (2005年09月22日)
Eric
On Monday 03 April 2006 22:16, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > Darren> Also, if I do the transform in backend_ps, instead of > Darren> passing it to the postscript interpreter, I see a big > Darren> speedup at render time. Right now I am doing this > Darren> transform by hand: > > Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y > Darren> = xo,yo > > Darren> Is there a better way to do this? I thought I could simply > Darren> call numerix_x_y, but that function is not compatible with > Darren> nonlinear transforms (returns a domain error if one of the > Darren> axes is log-scaled). > > You can transform the xy values point by point. Instead of separating > them into their nonlinear and affine components as we are currently > doing in backend_ps, you can call trans.xy_tup which will do both. If > successful, it will return the transformed xy, if it fails, it will > raise a ValueError, and you can set the moveto/lineto state > accordingly. I see a draw_lines_testing in backend_ps. I think it could be a good approach, but it doesnt make it very easy to skip unplottable elements like nans, infs. Could xy_tup accept a kwarg to make it raise an error when it tries to transform an inf or a nan? Darren
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> I see a draw_lines_testing in backend_ps. I think it could Darren> be a good approach, but it doesnt make it very easy to Darren> skip unplottable elements like nans, infs. Could xy_tup Darren> accept a kwarg to make it raise an error when it tries to Darren> transform an inf or a nan? I don't see why not. Alternatively, the nan testing could be done in "drawone". I was planning on filtering the path in chunks (eg 100 verts at a time) through drawone using map or listcomps, which should be faster and will not violate the max path size of some postscript interpreters. But I didn't get that far when my wife made me go to bed. So if you want to pick up where I left off, feel free. JDH
On Tuesday 04 April 2006 16:48, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> I see a draw_lines_testing in backend_ps. I think it could > Darren> be a good approach, but it doesnt make it very easy to > Darren> skip unplottable elements like nans, infs. Could xy_tup > Darren> accept a kwarg to make it raise an error when it tries to > Darren> transform an inf or a nan? > > I don't see why not. Alternatively, the nan testing could be done in > "drawone". I was planning on filtering the path in chunks (eg 100 > verts at a time) through drawone using map or listcomps, which should > be faster and will not violate the max path size of some postscript > interpreters. But I didn't get that far when my wife made me go to > bed. So if you want to pick up where I left off, feel free. Ok, I finished it off, unmasked it, and made similar changes to draw_markers. Changes in svn 2257. Darren