RE: [Matplotlib-users] large data sets and performance

[Perry G. <pe...@st...>]

John Hunter writes:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>     Perry> I like the sounds of this approach even more. But I wonder
>     Perry> if it can be made somewhat more generic. This approach (if
>     Perry> I read it correctly seems to need a backend function for
>     Perry> each shape: perhaps only for circle?). What I was thinking
>     Perry> was if there was a way to pass it the vectors or path for a
>     Perry> symbol (for very often, many points will share the same
>     Perry> 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).

>     Perry> I suppose circle and other curved items could be handled
>     Perry> 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
>