Quiver

[John_Hunter1]

Also, a question: why use collection objects? The

    > implimentation doesn't strike me as being much faster
    > rendering wise, but maybe I'm wrong. Is it just so all
    > the objects can be manipulated all at once by changing the
    > state of the collection?

collections aren't as fast as they can be, mainly because they use
sequences of python objects rather than numeric arrays, so all the
object coercion still has to be done. Their primary efficiency is the
avoidance of repeated object creation and their attendant function
calls and setting the graphics contect.

Eg, if you create 10000 Line2D objects, you will pay for 10000 object
creations, 10000 separate transformations, 10000 calls to the renderer
draw function, and 10000 settings of the gc state.

With a collection, you have a lot less overhead, but they are still
too slow for some purposes.

    > Also, is there any particular
    > reason the collections only accept verts or segments,
    > instead of being able to just send it a patch or line
    > object and have the collection object extract the relevant
    > data?

Currently the collections are designed to be flexible (eg, each polygon can
have separate color and width properties) and reasonably fast. They
are not particularly easy to use, so some helper functionality would
be useful.

JDH

[Jordan_Dawe3]

    > Also, a question: why use collection objects? The
    > implimentation doesn't strike me as being much faster
    > rendering wise, but maybe I'm wrong. Is it just so all
    > the objects can be manipulated all at once by changing the
    > state of the collection?

collections aren't as fast as they can be, mainly because they use
sequences of python objects rather than numeric arrays, so all the
object coercion still has to be done. Their primary efficiency is the
avoidance of repeated object creation and their attendant function
calls and setting the graphics contect.

Eg, if you create 10000 Line2D objects, you will pay for 10000 object
creations, 10000 separate transformations, 10000 calls to the renderer
draw function, and 10000 settings of the gc state.
  

Cool, that makes sense. Another question: what plot types generate 10000 Line2D objects? I can see quiver doing something like that if one plots an 100x100 grid, but it seems to me the resulting arrows would be totally unreadable.

I hope I'm not coming across as snotty here. I really love matplotlib, it's all I use nowadays, and quite an amazing piece of code. I want to find someplace where I can start adding functionality, but the backend is really confusing me. I guess I'm trying to figure out what bits of the code are design decisions and what bits are there because they worked, but aren't necessarily the best solution.

    > Also, is there any particular
    > reason the collections only accept verts or segments,
    > instead of being able to just send it a patch or line
    > object and have the collection object extract the relevant
    > data?

Currently the collections are designed to be flexible (eg, each polygon can
have separate color and width properties) and reasonably fast. They
are not particularly easy to use, so some helper functionality would
be useful.
  

Cool, so I take this to mean it would be helpful to add some code to the __init__() funcs of the collection objects so they can accept objects as well as vertex data? Cause I think I could do that.

So, are the basic drawing primitives in matplotlib Line2D, LineCollection, Patch, and PolyCollection, with QuadMesh a special case so that pcolor renders fast?

Jordan

[Eric_Firing2]

Jordan, Gary,

I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be preserved or not, depending on the units one chooses. Below a threshold, the whole arrow is scaled down as its length is reduced; above that threshold, only the length changes. I am subclassing PolyCollection, so there is full flexibility in rendering with or without an edge.

I expect I will be ready to commit something within a week.

Eric

[_gary_ruben1]

This is good news Eric and sounds like the desired behaviour.
Thanks for letting me know. I was intending to try to work it out this weekend but have spent my time instead learning to build numpy/scipy/matplotlib from source - a worthwhile exercise. I don't think JDH/Charlie should wait for new quiver plots before doing another release.

On the scaled down arrows, do you see strange artifacts when viewing at certain magnifications? JDH thought this might be due to subpixel rendering problems, although I wasn't sure that was the reason. I look forward to seeing how the transform stuff works. I found it all a bit unfathomable.

thanks,
Gary

Eric Firing wrote:

···

Jordan, Gary,

I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be preserved or not, depending on the units one chooses. Below a threshold, the whole arrow is scaled down as its length is reduced; above that threshold, only the length changes. I am subclassing PolyCollection, so there is full flexibility in rendering with or without an edge.

I expect I will be ready to commit something within a week.

Eric