Re: [matplotlib-devel] refactoring the backend drawing methods

[John H. <jdh...@ac...>]

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> Though the idea of having a minimal set of draw methods is
    Paul> esthetically appealing, in practice having to reuse these
    Paul> few commonly drawn methods to construct simple compound
    Paul> objects can become cumbersome and annoying.  I would suggest
    Paul> taking another look at Adobe's PDF language and Apple's
    Paul> Quartz (or display PDF).  It is iteresting to see that each
    Paul> new version adds one or two new draw methods, e.g. rectangle
    Paul> and rectangles, to make it easier and faster to draw these
    Paul> common paths. I'm guessing these new methods are based on
    Paul> copius experience.

I think the ideas has a lot of merit -- it's in keeping with the Tufte
philosophy "copy the great architectures" --
http://www.uwex.edu/ces/susag/Design/tufte.html -- which I tend to
agree with.  The current design is built on the GTK drawing model,
which is good but not great.  

The clear benefits of your suggestion that I see are that 1) it would
make matplotlib work as a front end to the kiva renderer, which might
ease it's integration into envisage, 2) we would get a PDF backend and
Aqua backends for free, and 3) it would also free us from having to
think about the design -- as you note that problem hasalready been
solved.

But there are some downsides too.The problem is that Quartz is a high
level drawing API.  Forcing every backend to implement the Quartz API
in order to qualify as a matplotlib backend is a fairly high barrier
to entry.  My idea is that the matplotlib front end should implement
these convenience functions, which they already do in patch.Rectangle,
patch.Circle, Line2D._draw_plus and so on, and the life of the backend
implementer should be as easy as possible.  They draw the primitives
and the front end does the rest.  

You are right that doing everything with draw_path can be less
efficient, but I feel like we have enough experience under our belt at
this point to know where the bottlenecks are.  If the matplotlib front
end code is designed right, we won't need to make 18 million calls to
draw_rectangle -- in which case you want your rectangle drawing
function to be damned efficient -- we'll call draw_markers or use a
polygon collection.

We could have the best of all worlds of course.  If we implement the
Quartz API and have all the base class methods call the low level
backend method draw_path, allowing different backends to override
selected methods where desired for performance, then we preserve the
low barrier to entry -- just implement draw path and a few more bits
-- and get kiva compatibility, a pdf backend, an aqua backend and a
solid backend API which we don't have to think a lot about.  It's also
a lot more work, of course, which I don't really have time for right
now.  But if you're offering....  I will take another look at it
though.

As an aside, a funny story.  After talking to you at scipy about the
Quartz API, I ordered the PDF reference from Adobe on Amazon.
Apparently, Amazon had changed the defaults in my one-click settings
and the book went to my mom by default.  My mom likes computers, but
the PDF specification is a bit much for her.  Perplexed, she first
called up my sister and asked her if she knew what was going on and my
sister replied, "John told me he was sending you a book he was really
excited about", referring to an unrelated conversation between us.  So
then my mom called me, trying to be thankful for the book I had sent
her.  When I finally figured out what was going on and explained to
her that she had gotten the PDF spec by mistake, she was audibly
relieved.

    Paul> While you are at it, I would suggest looking at the clipping
    Paul> issue.  As in PS and PDF, a path can be used as a clipping
    Paul> region.  This allows the backend, in PS and PDF, to do the
    Paul> clipping for you, which can make the code simpler and also
    Paul> faster.  Clipping using arbitrary paths may currently be an
    Paul> issue for AGG, but in my opinion, it is something that AGG
    Paul> will eventually have to come to grips with.

Arbitrary clipping paths are a priority for me, and agg does support
them now with the scanline boolean algebra -- see the recently update
http://matplotlib.sf.net/goals.html page for more information and
links.  Implementing paths in matplotlib is a first step to supporting
arbitrary clipping paths, which are currently needed for Jeffrey
Whittaker's basemap extension.

JDH