I'm sure it's obvious, but the backend API was never really designed
with this in mind. It was designed for "dumb" things like screens and
printers that know about simple primitives like lines and text, but not
much else. From that, I don't think it makes much sense to change or
even extend that API, as the current targets of the backends are not
going to suddenly get any smarter. You also have to remember that the
drawing commands that matplotlib emits to a backend are essentially a
stream -- they don't have the necessary structure (in all cases) to
write out to something like d3. You really want tree traversal, IMHO,
not a stream of commands.
For a long time, I've felt what is needed is a standard way to navigate
over the tree that makes up the figure -- something like a DOM. So you
would start at the root (the "figure") and drill down through all of the
objects, getting their properties such as location, data and drawing
styles and convert into some other format as you go. Your code wouldn't
have to care about what coordinate space the data is in -- it would have
access to the raw data and any custom transformations the user specified
etc., and it could handle accordingly. There's two major pieces that
make this hard right now. One is that each class has some arbitrary set
of "children", and there's no uniform way to iterate over them. If each
Artist had a children method that returns a list of its children, you
could write a "Visitor" pattern [1] class over the tree that would let
you write out your output format.
The second problem, as you point out, is that some things aren't really
calculated until draw time. In some cases, we could just be doing more
in the constructor. In other cases, we can't calculate the final
locations of things until we know things like font size etc., but
hopefully those aren't the cases a tool to write d3 would care about. I
could also imagine doing drawing in two phases, if necessary, one to
just finalize things, and the other to actually write to a "dumb"
backend. A d3 converter would only do the first phase, and then iterate
over the tree to generate its output.
[1] See Python's ast module or docutils for great examples of this
pattern. docutils is a particular good analogy because it converts text
in one complex logical structure (reStructuredText) to n different other
logical structures (including HTML and LaTeX etc.)
I hope all of the above makes sense...
Mike
On 01/14/2014 01:30 PM, Jacob Vanderplas wrote:
Thanks - we'll make it happen at some point.
Perhaps I can give the seed for a discussion: the stuff I've been
doing with mpld3 is a lot of fun, but it's fundamentally limited by
the fact that I have to dig around the internals of the figure object
to find the relevant information to construct a plot representation.
I may be able to do the same thing by creating a backend, but the
problem is that the draw() methods of most objects call the renderer
with no reference to whether the points lie in the data space or
figure space: that is, paths and points are usually specified in
figure/pixel coordinates or some transformed version thereof, which
makes it near impossible to construct interactive representations
absent Python kernel callbacks.
What I'd love to see is some enhancement of the backend framework
where there are some extra flags and information passed to the
renderer: i.e. for each draw command, we need to know whether the
drawn object should be linked to static figure coordinates or to
dynamic axes/data coordinates.
I've been in touch with Cyrille Rossant from the vispy team, Chris
Beaumont from the Glue team, and Matt Sundwuist from the plotly team,
all of whom asked if there might be a way to use what I've done with
mpld3 to enable matplotlib to export into their own front-end format.
I didn't start mpld3 with that sort of extensibility in mind, but I'm
starting to invest some time thinking about how to design that.
With the current matplotlib package, I think there are two ways to
accomplish it: one is to create a general backend-like interface based
on the figure introspection that mpld3 currently uses. The artist
elements in each figure contain enough information to be able to infer
whether the elements should move & zoom with the axes or not. The
problem is, a lot of elements (like legends, axes aspects, etc.) are
not fully established until the draw() command is called, so there are
a few ugly hacks required to make it happen.
The other option is to use an even uglier hack, and wrap the current
backend framework with an object that somehow links back into the
figure and infers from the draw_*() commands whether the
path/point/marker/etc. should be drawn in static figure coordinates or
in dynamic axes coordinates. I've started a simple prototype backend
translator which has a renderer class that uses ``inspect`` back-trace
the stack and accomplish this: It's really ugly, and I'm not
particularly proud about it, but I think it's the current best way to
accomplish the desired behavior.
Ugly hacks aside, I think all of this points to a general desire for a
new type of backend-like hook that can export dynamic plot elements in
data coordinates, and static plot elements in figure coordinates. An
enhancement in that direction could pave the way for a lot of
interesting interactive front-ends to matplotlib figures.
Anyway - if any of you have suggestions or responses to this, I'd love
to hear them! Thanks,
Jake
On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom <md...@stsci.edu
<mailto:md...@stsci.edu>> wrote:
Jake: I'd definitely like to get you into one of these calls at
some point. If you're able to pop in late, that would still be
great -- or we can save that for another date. Trying to get
Japan, three NA timezones and the UK all together is challenging ;)
In any event, with Thomas, Ben, Michiel and myself confirmed, I
think that's enough to go ahead, and hopefully others who have yet
to respond can join as well.
Mike
On 01/14/2014 11:57 AM, Jacob Vanderplas wrote:
I'll probably not be able to swing 6am on the west coast, but
other folks are more important for this call, I think :)
Jake
On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root <ben.r...@ou.edu
<mailto:ben.r...@ou.edu>> wrote:
That would actually work a little bit better for me... I just
have to remember to get into work a little bit earlier.
Ben
On Tue, Jan 14, 2014 at 11:36 AM, Michael Droettboom
<md...@stsci.edu <mailto:md...@stsci.edu>> wrote:
I'm fine with starting the meeting an hour early. How
about others?
Mike
On 01/14/2014 04:57 AM, Michiel de Hoon wrote:
> I can join this Thursday if we start with the
discussion on timers.
> If we can start 1 hour earlier (14:00 UTC, 9 am ET,
23:00 in Japan) that would be even better.
> -Michiel.
>
>
>
> --------------------------------------------
> On Mon, 1/13/14, Michael Droettboom <md...@stsci.edu
<mailto:md...@stsci.edu>> wrote:
>
> Subject: [matplotlib-devel] Meeting...?
> To: "matplotlib-devel@lists.sourceforge.net
<mailto:matplotlib-devel@lists.sourceforge.net>"
<matplotlib-devel@lists.sourceforge.net
<mailto:matplotlib-devel@lists.sourceforge.net>>
> Date: Monday, January 13, 2014, 11:36 AM
>
> It's probably a good time to schedule
> another matplotlib Google Hangout.
>
> Is this Thursday at 1500 UTC (10 am ET) too short
notice for
> the usual
> candidates?
>
> I know there was discussion of getting Michiel de Hoon on
> today (which I
> just saw, unfortunately). Is there another time in the
> future that
> works for you, Michiel?
>
> Mike
>
> --
>
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _
> _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
>
------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud
Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud
> For
> Critical Workloads, Development Environments &
> Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything
In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In
Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
