large data sets and performance

I like the sounds of this approach even more. But I wonder

    > if it can be made somewhat more generic. This approach (if
    > I read it correctly seems to need a backend function for
    > each shape: perhaps only for circle?). What I was thinking
    > was if there was a way to pass it the vectors or path for a
    > symbol (for very often, many points will share the same
    > shape, if not all the same x,y scale).

Of course (slaps self on head). matplotlib 0.1 was designed around
gtk drawing which doesn't support paths. Although I've been mumbling
about adding paths for sometime (what with paint, ps, and agg), I'm
still thinking inside the box. A collection of paths is the natural
solution

    > I suppose circle and other curved items could be handled
    > with A bezier type call.

Agg special cases this one with a dedicated ellipse function.

  ellipse(ex, y, width, height, numsteps)

It's still a path, but you have a dedicated function to build that
path up speedily.

One potential drawback: how do you bring along the other backends that
don't have path support? In the RectangleCollection approach, we can
always fall back on draw_rectangle. In the path collection, it's more
difficult.

  backend_gtk (pygtk) - no support for paths AFAIK
  backend_wx (wxpython) - no support for paths AFAIK; Jeremy?
  backend_ps - full path support
  backend_agg - ditto
  backend_gd - partial, I think; gotta check
  backend_paint (libart) - full, perhaps with bugs

JDH

John Hunter writes:

    > I like the sounds of this approach even more. But I wonder
    > if it can be made somewhat more generic. This approach (if
    > I read it correctly seems to need a backend function for
    > each shape: perhaps only for circle?). What I was thinking
    > was if there was a way to pass it the vectors or path for a
    > symbol (for very often, many points will share the same
    > shape, if not all the same x,y scale).

Of course (slaps self on head). matplotlib 0.1 was designed around
gtk drawing which doesn't support paths. Although I've been mumbling
about adding paths for sometime (what with paint, ps, and agg), I'm
still thinking inside the box. A collection of paths is the natural
solution

Based on your previous description of collection of circles, I think
so (though I wonder about the name, paths may imply many independent
paths whereas I'm implying that sharing of one path for a collection
of points. Since circles are all identical in shape, that confusion
doesn't exist with the plural.

But I can see this approach being used for things like error bars
(one can view them as scalable symbols).

    > I suppose circle and other curved items could be handled
    > with A bezier type call.

Agg special cases this one with a dedicated ellipse function.

  ellipse(ex, y, width, height, numsteps)

It's still a path, but you have a dedicated function to build that
path up speedily.

One potential drawback: how do you bring along the other backends that
don't have path support? In the RectangleCollection approach, we can
always fall back on draw_rectangle. In the path collection, it's more
difficult.

Maybe I'm still missing something, but couldn't paths be implemented
using the backend lines primitive? After all, any path is a finite
set of lines (unless you are using bezier curves). And if lines
are available in python, the loop could also be coded in C.
Now it is true that some backends don't have the concept of
defining a path that can be reused with different coordinate
transforms. But that isn't needed for the functionality of rendering
it, is it. It just makes it a bit more work to keep rendering the
same set of points with different offsets and scales (i.e., you
must keep giving the transformed path array(s) to the backend to render
within a loop (in python or C). Right?

Perry

···