It might be worth generalizing this to take some optional
> array/scalar arguments to apply marker by marker scaling
> (or even independent x/y scaling) as well as overrides to
> some gc items (e.g. color). This doesn't need to be done
> right away, but may provide some very useful capability
> (e.g., error bars could be done as markers if y or x size
> could be scaled for every x,y location.
What you are describing is basically the draw_*collection methods.
But my experience with them has led me to believe these methods are
not ideal -- for example the i%N indexing of collections is
syntactically convenient but practically rarely useful. In real life,
for a given property, you either want a shared property (marker color)
or you want that property to be different at every pointt (scatter
color with a cmap). And in cases where you have a few properties,
each with lots of segments (read contour) it's fine to create a few
objects rather than have one monolithic object (as Nadia did).
One nice thing about the current draw_marker implementation is that it
is easy (it uses a gc, like all the other drawing methods). Once we
permit scalex and scaley, we'll also want to add rgba (with scalex,
scaley, and rgba as possible len(x) sequences, it could handle
scatters). And then once you allow all these to vary, you might start
thinking about letting every property vary, which is what collections
already do, and which apparently are sufficiently complex that
everyone but agg falls back on the base class implementation, which
while a good bit faster than the bad old days, is still slower than it
should be.
On the subject of speed, the new draw_markers *is* fast. Close to as
fast as you can get, I'd venture, for anti-aliased drawing with alpha
support. I spent a lot of time in the profiler and there isn't much
fat left to be trimmed -- most of the cost is now pure agg, and it's
agg that Maxim helped me optimize by using cached rasters. None of
this precludes your idea, though, because agg is so damned cool that
you can scale and colorize cached rasters pretty cheaply. FYI, here
are my latest benchmark numbers on draw_markers in agg
0.71 CVS speedup
···
-----------------------------------
N = 1000 | 0.24s | 0.13s | 1.85x
N = 5000 | 0.68s | 0.19s | 3.57x
N = 10000 | 1.17s | 0.28s | 4.19x
N = 50000 | 5.30s | 0.60s | 8.89x
N = 100000 | 10.02s | 0.70s | 14.31x
N = 500000 | 48.81s | 2.32s | 21.03x
As an aside, errorbars, which you mentioned, present a slightly more
complicated case, because the errorbar caplines scale independently of
the x and y error scale.
After discussions with Fernando, who never tires of pointing out the
joys of gnuplot to me :-), I've come to agree that matplotlib ought to
extend the Artists to include "plot items" classees; eg a plot command
should create a LineItem, a scatter command should create a
ScatterItem, an errorbar plot should create and ErrorbarItem. And we
should have, like gnuplot, FuncItems and a few more. This would
satisfy something about the design that has always bothered me --
where should the fundamental plot type functions go? Currently they
are axes methods but this has always stuck me as wrong -- it just
doesn't have the right feel. I think that having high level artists
like ErrorbarItem, which contain the primitives necessary to draw
them, might be the way to go. One could then mix and match various
plot items in different axes and figures.
This might also make the pure OO users happier, who sometimes grumble
that the OO interface is too hard to use.
JDH