dot markers

Community matplotlib-users
1

The behavior of the '.' marker seems anomalous, very

    > different between gtkAgg and postscript backends, and not
    > very useful:

Hi Eric,

All of your suggestions for '.' are totally reasonable. Perhaps you
can implement it? After implementing much of the contouring and
masked array support, I think you'll find this one relatively
painless.

A few things to be aware of:

  * the PS and *Agg backends should not be different. A few months
    ago I suggested a new API for backend drawing which added the
    method renderer.draw_markers (search the dev list for
    draw_markers). Most of the backends have not implemented it yet,
    which is why we have conditionals in lines.py like

    def _draw_point(self, renderer, gc, xt, yt):
        if self._newstyle:
            rgbFace = self._get_rgb_face()
            path = agg.path_storage()
            path.move_to(-0.5, -0.5)
            path.line_to(-0.5, 0.5)
            path.line_to(0.5, 0.5)
            path.line_to(0.5, -0.5)
            renderer.draw_markers(gc, path, rgbFace, xt, yt, self._transform)
        else:
            for (x,y) in zip(xt, yt):
                renderer.draw_arc(gc, None, x, y, 1, 1, 0.0, 360.0)

    _draw_point is the function that draws the marker style '.' -- see
    the Line2D._markers dictionary.

    I suggest you modify _draw_point to work like you suggest, for
    both the "newstyle" and old cases. "newstyle" is a boolean which
    is True iff renderer.draw_markers is implemented (Agg only, I
    think). One of the main reasons I implemented draw_markers was to
    avoid the overhead of calling a renderer draw function for each
    marker. As note in the release notes at
    http://matplotlib.sourceforge.net/whats_new.html, these changes
    were introduced in mpl 0.72 and can be 20x faster for large
    numbers of points (eg 500K points).

  * matplotlib already has marker style ',' for draw_pixel, and so
    your interpretation of draw_point is fine. When someone wants a
    pixel, they can call plot(x, y, ',')

Let me know if you have any more comments or questions.

Thanks,
JDH

2

John, Jeff,

As I mentioned a couple weeks ago, I found that the CVS change to colorbar breaks contourf if called with explicit colors rather than a colormap. I think this is just a symptom of deeper problems in contour.py, so I have been trying to improve the whole system before dealing with the specific colorbar problem. I have found it very difficult to keep track of what is going on in the present system, particularly with respect to the "mappable" object that gets tacked onto the list of collections that contour and contourf return. I think the root of the problem is the tension between OO design and the non-OO matlab compatibility of the present contour and contourf functions, combined with the minimally OO construction of the ContourHelper class (which is mostly a package of functions). Now, the functions return (levs, collections), where levs is the list of contour levels and collections is a silent_list of collections with an attached ContourMappable object. What I want to do instead is return a single object that includes everything useful; it inherits from ScalarMappable (like collections do), it includes the levels, the list of collections, and all the various relevant attributes of the contour plot. Passing this object to a colorbar function or a clabel function then makes it much easier for these functions to do the right thing--they get the necessary information in a single straightforward package.

So, the big question is: is it OK, or at least potentially OK, to change the pylab API for contour and contourf so that they return a single object instead of a tuple? I am part-way there, and I think going the rest of the way would be good for the long-term usability and maintainability of mpl. But I don't want to go the rest of the way, which will affect many files and also break some users' programs, if this is judged to be too radical a change, or otherwise undesirable.

Eric

3

This breaks the matlab analogy.
I do not care about that myself,
but people coming from matlab might.
Maybe the right way to go is to provide an extended
contourgroup object
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/contourgroupproperties.html
and treat contour and contourf as convenience functions that
continue to work as they do.

fwiw,
Alan Isaac

···

On Wed, 07 Sep 2005, Eric Firing apparently wrote:

So, the big question is: is it OK, or at least potentially
OK, to change the pylab API for contour and contourf so
that they return a single object instead of a tuple?