matplotlib-devel Mailing List for matplotlib

On 01/14/2014 03:49 PM, Chris Beaumont wrote:
> I have another long-simmering feature request along these lines: if 
> Matplotlib were to evolve a formal DOM-like figure structure like 
> mentioned above, it would be cool if this structure retained more 
> semantic information about the visualization itself. By this, I mean 
> that many high-level commands like hist, scatter, etc. spawn a bunch 
> of low level artists like rectangles and circles. After these methods 
> exit, it's hard/impossible to introspect a Figure and diagnose that 
> it, for example, is a histogram and not a bar chart.
I agree, this would be very nice to have, but is (obviously) a much 
bigger step from what we currently have in matplotlib. Along those 
lines, if the "frontend" (i.e. the pylab interface and even the OO 
interface) basically generate a tree, then you could serialize that tree 
(here XML would be a great fit, don't knock it), and even non-Python 
based tools could transform it into something else.
>
> Retaining a better high-level description of a plot (which probably 
> amounts to creating more compound artist types) would make it easier 
> to build tools like mpld3 and other cool things that involve runtime 
> editing or optimization of tree-like data structures.
Agreed.
No argument against this at all from me -- but knowing how much work 
this would be, the obstacle there is just finding the time to do it. It 
would be a significant rewrite...
Mike
>
> chris
>
>
> On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas 
> <ja...@cs... <mailto:ja...@cs...>> wrote:
>
> On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom
> <md...@st... <mailto:md...@st...>> wrote:
>
>
> I hope all of the above makes sense...
>
>
> Definitely makes sense: what I've built-up in mpld3 is essentially
> something that mimics this sort of visitor pattern, though it
> misses some things because of the draw-time difficulties you mention.
> I think a two-stage draw() would be a _very_ helpful restructure.
> Currently, I'm forced to achieve this result by writing a png to
> a throwaway byte-stream...
> Jake
>
>
> 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...@st... <mailto:md...@st...>> 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...@ou... <mailto:ben...@ou...>> 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...@st... <mailto:md...@st...>> 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...@st... <mailto:md...@st...>> wrote:
>>> >
>>> > Subject: [matplotlib-devel] Meeting...?
>>> > To: "mat...@li...
>>> <mailto:mat...@li...>"
>>> <mat...@li...
>>> <mailto:mat...@li...>>
>>> > 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
>>> > Mat...@li...
>>> <mailto:Mat...@li...>
>>> >
>>> 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
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> 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
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> 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
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> -- 
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont>
> ************************************
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

On 01/14/2014 03:43 PM, Cyrille Rossant wrote:
>> 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.
> +1. It would also be nice to have the possibility to bypass dynamic
> data transformations performed by matplotlib. A potential GPU-based
> backend would be the most efficient if it was granted the right to
> perform all data transformations by itself (for example when panning
> and zooming).
>
In the specific case of data transformations, this is already the case. 
The backends are sent the raw data + a transformation. This allows file 
formats to write out untransformed data and have the renderer of that 
format do the transformation. Unfortunately, all of the backends end up 
doing the transformation in software anyway, since all of them scale the 
line width along with the path data, which is never what you want for 
plotting. (The exception to this is the SVG spec, which now contains a 
flag for this, but that spec is so new we can't use it because it isn't 
widely implemented).
Mike
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com