matplotlib-devel Mailing List for matplotlib

On Monday 04 April 2005 12:09 pm, John Hunter wrote:
>
> I agree ticks (and text in general) are too expensive. In my
> experience, this is usually only starts a problem in animated plots
> (do you have another use case in mind?). I think we might be able to
> work around this particular problem by supporting the drawing of only
> a subset of the artists in the scene. 
[...]
>
>
> I'm not opposed to a redesign of the Tick drawing if there are
> appreciable gains to be had, but my guess is we may get more bang for
> the buck in special casing the typical text layout (angle=0.0, no
> mathtext, no unicode) and handling dynamic updates more intelligently.
Data acquisition is a good example of where a new tick protocol would be 
useful. Supposing the user wants a plot in their gui that autoscales after 
the addition of each new point (which is not uncommon), the ticks would need 
to render as quickly as possible.
Everytime somebody I work with complains about the LabView program from 
National Instruments, I think about how nice it would be to do data 
acquisition with Python. I had hoped that Taco would mature into a solid 
library for interfacing with scientific instruments, but the project doesnt 
seem very active, judging by their webpage http://www.esrf.fr/taco/.
-- 
Darren

Hi John,
Hmm, could be. Text is definitely slow, but my recollection is
that the Line2D drawing of the ticks was actually significant.
For example, the speed difference when turning on/off the right
and top ticks (which don't generally have text) was noticeable.
It's been awhile since I looked at this, and I'm not finding my
test scripts right now. My conclusions at the time were that
agg rendering was dominating WXAgg time (so improving the WXAgg
icky get-rgb-image-then-render-as-bitmap was not so slow) and
that tick line rendering in Agg was much slower than I had
expected. I'll try to reproduce this, but this week is sort of
full for me. Currently, line plotting with WXAgg is fast enough
for me (I can reliably get better than 10 plots/sec on WinXP in
my app, for example).
Also, just to be clear: I owe you much more than doughnuts.
Thanks,
--Matt
On Mon, 4 Apr 2005, John Hunter wrote:
> >>>>> "Matt" == Matt Newville <new...@ca...> writes:
> 
> Matt> I like Darren's and Paul's suggestion (set line properties
> Matt> once, then have the ticks be a simple list of pen up / pen
> Matt> down). I believe major and minor ticks would need to have
> Matt> different properties, but it's still only 2 set of
> Matt> properties. I understand that this might mean a significant
> Matt> redesign, but the performance boost might be worth it.
> 
> I would bet dollars to doughnuts (careful here, Perry still owes me a
> doughnut!) that almost all of the tick cost comes from laying out the
> text of the ticks and not in drawing the tick lines themselves -- Arnd
> posted some hotshot profile of this earlier, but I don't remember the
> exact results).
> 
> I agree ticks (and text in general) are too expensive. In my
> experience, this is usually only starts a problem in animated plots
> (do you have another use case in mind?). I think we might be able to
> work around this particular problem by supporting the drawing of only
> a subset of the artists in the scene. I imagine something like the
> following is workable.
> 
> line, = ax.plot(blah)
> 
> dynamic = (line,) # a list of artists to animate
> # draws everything but artists in dynamic and caches Axes bbox to bitmap
> ax.animate_prepare( dynamic) 
> 
> while 1:
> line.set_data(blah)
> # blits the axes background cache and renders only the artists in dynamic
> ax.animate() 
> 
> 
> I'm not opposed to a redesign of the Tick drawing if there are
> appreciable gains to be had, but my guess is we may get more bang for
> the buck in special casing the typical text layout (angle=0.0, no
> mathtext, no unicode) and handling dynamic updates more intelligently.
> 
> JDH
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

>>>>> "Matt" == Matt Newville <new...@ca...> writes:
 Matt> I like Darren's and Paul's suggestion (set line properties
 Matt> once, then have the ticks be a simple list of pen up / pen
 Matt> down). I believe major and minor ticks would need to have
 Matt> different properties, but it's still only 2 set of
 Matt> properties. I understand that this might mean a significant
 Matt> redesign, but the performance boost might be worth it.
I would bet dollars to doughnuts (careful here, Perry still owes me a
doughnut!) that almost all of the tick cost comes from laying out the
text of the ticks and not in drawing the tick lines themselves -- Arnd
posted some hotshot profile of this earlier, but I don't remember the
exact results).
I agree ticks (and text in general) are too expensive. In my
experience, this is usually only starts a problem in animated plots
(do you have another use case in mind?). I think we might be able to
work around this particular problem by supporting the drawing of only
a subset of the artists in the scene. I imagine something like the
following is workable.
 line, = ax.plot(blah)
 dynamic = (line,) # a list of artists to animate
 # draws everything but artists in dynamic and caches Axes bbox to bitmap
 ax.animate_prepare( dynamic) 
 while 1:
 line.set_data(blah)
 # blits the axes background cache and renders only the artists in dynamic
 ax.animate() 
I'm not opposed to a redesign of the Tick drawing if there are
appreciable gains to be had, but my guess is we may get more bang for
the buck in special casing the typical text layout (angle=0.0, no
mathtext, no unicode) and handling dynamic updates more intelligently.
JDH

Hi John, 
On Mon, 4 Apr 2005, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> Darren> I think we could get a performance boost if all 
> Darren> similar ticks were passed together to draw_markers, 
> Darren> right now they a are passed independently.
>
> We could, but it would require some redesign. Tick is a
> class, and the axis contains a list of ticks. Thus it would
> take some top-level redesign.
I'd also encourage looking at how the Ticks are implemented. I
believe that for simple plots (say, simple_plot.py), the tick
drawing is what dominates rendering time, at least in the WxAgg
backend (which is dominated by the Agg rendering time). I
wouldn't be surprised if this was the case for most backends.
As far as I can tell, each tick mark is a separate Line2D with 2
points and have all the available properties of a Line2D. That
seems like a fine approach (certainly easy), but it's definitely
overkill. My speed tests say that rendering one thousand lines
with two points is a lot slower than rendering two lines with
one thousand points (easy enough to test). That means tick
drawing can easily be the performance bottleneck.
I like Darren's and Paul's suggestion (set line properties once,
then have the ticks be a simple list of pen up / pen down). I
believe major and minor ticks would need to have different
properties, but it's still only 2 set of properties. I
understand that this might mean a significant redesign, but the
performance boost might be worth it.
Thanks,
--Matt
PS: Someone might want tick marks to have all the flexibility
that they currently enjoy. My guess is that this would be
unusual (I don't see any examples that use this flexibility),
and that such cases could just add custom lines themselves.

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> The coordinates (80.640 31.680) are rendered twice; I can
 Darren> comment one of these lines out of the PS file and the tick
 Darren> still renders. Its not a bug in draw_markers, the square
 Darren> data markers are only rendered once, it seems to be
 Darren> specific to tickmarks.
Strange.... I'll look into this later.
 Darren> I think we could get a performance boost if all similar
 Darren> ticks were passed together to draw_markers, right now they
 Darren> are passed independently.
We could, but it would require some redesign. Tick is a class, and
the axis contains a list of ticks. Thus it would take some top-level
redesign. 
 Darren> Yeah, I realized I had made a boneheaded observation just
 Darren> after I hit the send button.
It's always that way :-) That is what the send button is for: self
enlightenment.
 Darren> OK. Would you add the signature to backend_bases?
Not yet. I was just suggesting you use this internally.
 def draw_markers(self, gc, path, rgbFace, x, y, transform):
 self.push_gc(gc)
 while 1: 
 .... snip...
and later when it becomes part of the api, you'll already have done
the hard part. You can also call this function from draw_ps.
Basically, all you need to do is rip the gc setting part of out of
draw_ps.
JDH

Darren Dale wrote:
>% draw_markers 
>/marker { gsave
>newpath
>translate
>0.000 0.000 m
>0.000 4.000 l
>closepath
>stroke
>grestore } bind def
>0.500 setlinewidth
>0 setlinecap
>80.640 31.680 marker
>80.640 31.680 marker
>stroke
>
>The coordinates (80.640 31.680) are rendered twice; I can comment one of these 
>lines out of the PS file and the tick still renders. Its not a bug in 
>draw_markers, the square data markers are only rendered once, it seems to be 
>specific to tickmarks. 
>
>I think we could get a performance boost if all similar ticks were passed 
>together to draw_markers, right now they are passed independently.
> 
>
Yes, this would be good, since the same marker could be save and then 
just translated from position to position.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Hi John,
>
> Darren> 2) I think each tickmark is listed in agg.path_storage
> Darren> twice, and therefore gets rendered twice in PS.
>
> Why do you think this? Which ticks?
I was checking the output of the files I was generating, here is a clip 
responsible for rendering a single xtickmark:
% draw_markers 
/marker { gsave
newpath
translate
0.000 0.000 m
0.000 4.000 l
closepath
stroke
grestore } bind def
0.500 setlinewidth
0 setlinecap
80.640 31.680 marker
80.640 31.680 marker
stroke
The coordinates (80.640 31.680) are rendered twice; I can comment one of these 
lines out of the PS file and the tick still renders. Its not a bug in 
draw_markers, the square data markers are only rendered once, it seems to be 
specific to tickmarks. 
I think we could get a performance boost if all similar ticks were passed 
together to draw_markers, right now they are passed independently.
> Darren> 5) Im not doing anything with vec6 =
> Darren> transform.as_vec6_val(). I'm not sure what it is used for.
>
> This is in case you want to do the affine transformation yourself.
> The transform is a nonlinear part plus an affine. Note that
> backend_ps is currently doing
>
> if transform.need_nonlinear():
> x,y = transform.nonlinear_only_numerix(x, y)
> x, y = transform.numerix_x_y(x, y)
>
> which is wrong -- it will fail for nonlinear transforms like log
> because the numerix_x_y call does the nonlinear and the affine part
> and so you will be doing the nonlinear part twice. 
I'll get up to speed on this eventually. I just copied those three lines from 
backend_cairo.draw_markers.
> Darren> 6) draw_lines is getting a long pathlist from agg.
>
> That is not surprising. matplotlib plots what you give it. 
Yeah, I realized I had made a boneheaded observation just after I hit the send 
button.
> Now, onto the subject of how you might be able to make this faster.
[...]
> It might be worth implementing a push_gc method
> that sets the current gc state, and then calling this at the top of
> draw_markers and not inside the loop. We'll probably want to
> implement this as a default gc method across backends anyway in the
> near term, so it would be a worthwhile change.
OK. Would you add the signature to backend_bases?
-- 
Darren