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.
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,
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:
> 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.
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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/.
···
On Monday 04 April 2005 12:09 pm, John Hunter wrote:
--
Darren