matplotlib-devel Mailing List for matplotlib (Page 2)

R Hattersley wrote
> I'm not sure what it is about CSS syntax that isn't up to the job.
> Forexample, SVG works with standard CSS syntax
> (seehttp://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just
> havea different view of what constitutes CSS vs. HTML/SVG/whatever.The
> example in the SVG spec is:
> rect { fill: red; stroke: blue; stroke-width: 3}
> But if we define the element name for a Line2D instance as "line2d"
> thenCSS snippet could just become:
> line2d { stroke: blue; stroke-width: 3}
You've just noted it: Line2D isn't a CSS selector..likewise, the properties
we want to call upon (like linewidth) are not CSS attributes. There are many
matplotlib properties that don't have an analogous CSS property/attribute
(that I know of); we might aswell define the mpl properties in our 'CSS'
subset.So we could base our language on CSS rules, but we need to define new
tokens. This means writing, or more likely, extending a parser. Not huge,
but not trivial. 
R Hattersley wrote
> The DOM facade could help bridge the gap. For example, a "DOM"
> instancereturned by an Axes object could pretend to have "text" element
> children.Styling those would route the style information back to the
> underlying Axesobject. For example:
> text { font-size: 12pt;}axes text.ylabel { font-size: 10pt;}
This could be one way. Another way that would fit and I quite like is
similar to what is employed by mapnik/the tilemill, in that we simply have
nested declaration blocks, e.g:
 Axes { gid: 'axes1'; autoscalex_on: True; ::ylabel
{ text: 'Y-Axis'; font-size: 10; 
} }
I think this would be easier to parse and slightly clearer to read as it can
be 'attached' to the artist container it refers to (imagine if there were 2
axes in a figure...). It is also easy to write in BNF, by just adding
another option to the Declaration block:
Rule := Selector '{' [Declaration] '}'Declaration := Attribute':' Value';' |
Rule...
But...small steps. I would start by introducing something for artist
primitives and for selectively applying to primitives using the gid 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43673.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On 20 July 2014 14:23, jamesramm <jam...@gm...> wrote:
> We cannot stick with the 'standard' CSS syntax by necessity, simply because
> the standard CSS selectors and properties are defined from HTML and do not
> match with matplotlib.
> I.E we want to select by artist type, which doesn't exist in HTML and use
> properties such as linewidth.
>
I'm not sure what it is about CSS syntax that isn't up to the job. For
example, SVG works with standard CSS syntax (see
http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have
a different view of what constitutes CSS vs. HTML/SVG/whatever.
The example in the SVG spec is:
rect {
 fill: red;
 stroke: blue;
 stroke-width: 3
}
But if we define the element name for a Line2D instance as "line2d" then
CSS snippet could just become:
line2d {
 stroke: blue;
 stroke-width: 3
}
Sure, matplotlib doesn't define a genuine DOM, but I understand there is
interest in moving to a model more like that. In which case, perhaps a good
way to proceed in the meantime would be to have artists expose a DOM facade
suitable for styling. (Perhaps even using SVG element conventions?)
NB. matplotlib already uses pyparsing, so it would be pretty
straightforward to knock together a parser for CSS (or whatever subset is
needed). Or there are existing Python CSS parser libraries.
> Qt - Pyside/PyQt ('QSS')
> Mapnik ('CartoCSS')
> PyGal supports stylesheets (don't know much about this library)
>
>
If we don't use CSS then +1 for using some other standard.
> As I say, an alternative could be simply using the ConfigParser
>
>
> Richard Hattersley wrote
> >>
> >> Do you have ideas on how one or more stylesheets would be "attached" to
> a
> >> particular figure, etc?
> >>
> >> Regards,
> >> Richard Hattersley
> >>
>
>
> b) Filtering artists
> Another problem is that we would generally want to treat artists which are
> solely for the construction of the Axes differently to those artists that
> define a plot. I.E we might want to define Line2D as having the colour red,
> but we want lines which compose the Axes to be black or grey.
> My initial proposal is to develop stylesheets for artist primitives only.
> But eventually we will want to style artist containers aswell.
> The problem matplotlib has is that the properties for artist containers are
> not uniform/intuitive.
> It generally has a API where artists which are 'contained' by other artists
> are set by calling properties...e.g. axes.set_ylabel(text = , etc...)
>
The DOM facade could help bridge the gap. For example, a "DOM" instance
returned by an Axes object could pretend to have "text" element children.
Styling those would route the style information back to the underlying Axes
object. For example:
text {
 font-size: 12pt;
}
axes text.ylabel {
 font-size: 10pt;
}
I would imagine setting stylesheets through the axes or figure methods
> (axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require
> being able to differentiate between different axes - i.e. introducing the
> 'container' level syntax I mentioned above.
>
> I would imagine that this would eventually replace rcparams to define the
> default style. I would also like to see the default look of graphs moving
> away from the very dated, 90's style MATLAB appearance!
>
That would be an excellent start. More complicated mechanisms can always be
added later if necessary.
Richard

Nelle Varoquaux wrote
>> I'd strongly encourage you to stick with standard CSS syntax/behaviour
>> instead of extending it. For example, the selector of "Axes.ylabel" would
>> be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label").
>>
> 
> I actually think we need to focus on something easy to parse and easy to
> use, not necessarily stick to the CSS syntax and behaviour. Back in the
> day
> where I was doing web development and design integration, everyone seemed
> to hate CSS, so I am a bit curious and dubious about this choice.
We cannot stick with the 'standard' CSS syntax by necessity, simply because
the standard CSS selectors and properties are defined from HTML and do not
match with matplotlib. 
I.E we want to select by artist type, which doesn't exist in HTML and use
properties such as linewidth.
So, we would need to define a new syntax based on these tokens. 
I have updated MEP26 with a BNF form of a basic syntax to use - take a look!
Another option would be to use the syntax for the ConfigParser module; this
way we already have a parser :)
Nelle Varoquaux wrote
> I think we need to be careful about the choice of the grammar and the API:
> we know there are tools that are "doing it right", and tools that aren't
> (matplotlib falls in the second category). Before trying our own recipe I
> suggest that we look elsewhere, on how other libraries are tackling this
> problem, to see if we can reuse some of the good ideas and avoid errors. I
> am thinking in particular about ggplot2 (which I have never used, but I
> hear is very nice).
> 
> Thanks,
> Nelle
I thought CSS would be a good language to base it on as it is a widely known
and by far the most popular (as far as I know) 'stylesheet' language.
Other libraries that use style sheets, based on some form of CSS are:
Qt - Pyside/PyQt ('QSS')
Mapnik ('CartoCSS')
PyGal supports stylesheets (don't know much about this library)
As I say, an alternative could be simply using the ConfigParser
Richard Hattersley wrote
>>
>> Do you have ideas on how one or more stylesheets would be "attached" to a
>> particular figure, etc?
>>
>> Regards,
>> Richard Hattersley
>>
This is the big question. We need a standard way in which to traverse all
the artists in a figure, filter them by the selectors and applying the
property updates.
The last part is easiest - the update() method on artists will accept a
dictionary. We can simply ensure that our stylesheet rules are parsed into a
dict structure (which is quite a common method to use).
The hard part is
a) Getting a complete figure description/traversing the artists.
This is currently tricky, but I think the ideas proposed in MEP25 will make
it much easier.
b) Filtering artists
Another problem is that we would generally want to treat artists which are
solely for the construction of the Axes differently to those artists that
define a plot. I.E we might want to define Line2D as having the colour red,
but we want lines which compose the Axes to be black or grey. 
My initial proposal is to develop stylesheets for artist primitives only.
But eventually we will want to style artist containers aswell. 
The problem matplotlib has is that the properties for artist containers are
not uniform/intuitive. 
It generally has a API where artists which are 'contained' by other artists
are set by calling properties...e.g. axes.set_ylabel(text = , etc...)
I would prefer to be able to simply pass a class instance...e.g create an
instance of Text() and pass that to set_ylabel()
I believe this is similar to the Plotly API that is quite nice:
https://plot.ly/python/line-and-scatter/
An ideal solution would be trying to seperate out the style of artists from
the actual drawing/data
PyGal accepts a `Style` instance as an arguement to it's plotting functions,
which would be a good way to go.
I would imagine setting stylesheets through the axes or figure methods
(axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require
being able to differentiate between different axes - i.e. introducing the
'container' level syntax I mentioned above.
I would imagine that this would eventually replace rcparams to define the
default style. I would also like to see the default look of graphs moving
away from the very dated, 90's style MATLAB appearance!
Anyway, there are a lot of ideas above, some of which are feasible, some of
which perhaps not, all of which need more thinking about!
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43671.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi James,
> Thanks for sharing the MEP - it's a really interesting idea, and the MEP
> itself looks like a good start.
>
It is indeed a very interesting idea, and a challenging one! Thanks for
tackling this problem.
> I'd strongly encourage you to stick with standard CSS syntax/behaviour
> instead of extending it. For example, the selector of "Axes.ylabel" would
> be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label").
>
I actually think we need to focus on something easy to parse and easy to
use, not necessarily stick to the CSS syntax and behaviour. Back in the day
where I was doing web development and design integration, everyone seemed
to hate CSS, so I am a bit curious and dubious about this choice.
I think we need to be careful about the choice of the grammar and the API:
we know there are tools that are "doing it right", and tools that aren't
(matplotlib falls in the second category). Before trying our own recipe I
suggest that we look elsewhere, on how other libraries are tackling this
problem, to see if we can reuse some of the good ideas and avoid errors. I
am thinking in particular about ggplot2 (which I have never used, but I
hear is very nice).
Thanks,
Nelle
>
> Do you have ideas on how one or more stylesheets would be "attached" to a
> particular figure, etc?
>
> Regards,
> Richard Hattersley
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi James,
Thanks for sharing the MEP - it's a really interesting idea, and the MEP
itself looks like a good start.
I'd strongly encourage you to stick with standard CSS syntax/behaviour
instead of extending it. For example, the selector of "Axes.ylabel" would
be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label").
Do you have ideas on how one or more stylesheets would be "attached" to a
particular figure, etc?
Regards,
Richard Hattersley

Hi,
I just started working on MEP26
<https://github.com/matplotlib/matplotlib/wiki/MEP26> to create a
stylesheet syntax & implementation for dynamic, artist-level stylesheets.
There is still a lot of work to be done on the MEP, but hopefully it is a
good starting point for discussion
Thanks
James

The defaults got reverted, but the baseline images did not.
Here's a branch with (un-?)updated baseline images:
https://github.com/phobson/matplotlib/commit/8b719e7bda4cef254fbe515e5dfc23d88f3ff5da
I based it off of master, should probably pull them into the 1.4.x branch
before submitting the PR.
-p
On Tue, Jul 15, 2014 at 11:28 PM, Lennart Fricke <le...@di...>
wrote:
> Hello Paul Hobson,
>
> you changed defaults in:
>
> commit 7df0313b010d211997cf391d1bee38e194db5618
> Author: Paul Hobson <pmh...@gm...>
> Date: Wed May 14 00:01:57 2014 -0700
>
> restored default boxplot style and respect for the sym kwa
>
> since then the plots look like they do now.
> Maybe we should change the baseline images.
>
> Best regards
> Lennart
>
>

Hello Paul Hobson,
you changed defaults in:
commit 7df0313b010d211997cf391d1bee38e194db5618
Author: Paul Hobson <pmh...@gm...>
Date: Wed May 14 00:01:57 2014 -0700
 restored default boxplot style and respect for the sym kwa
since then the plots look like they do now.
Maybe we should change the baseline images.
Best regards
Lennart

Hi,
I am trying to do some reorganization of the examples in the gallery by
moving the files into other directories.
I am using ack to look for references from other parts of the documentation
to those example files and have successfully caught most of them.
But now I am trying to move legend_demo.py from the api subdirectory of
examples, and when I compile the API docs, it says that it can't find the
file (error output below).
However, there does not seem to be anywhere that actually references that
file...
Can anybody suggest what is going on?
Thanks,
David.
reading sources... [ 0%] api/axes_api
Exception occurred:
 File
"/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.9-x86_64.egg/matplotlib/sphinxext/plot_directive.py",
line 718, in run
 with io.open(source_file_name, 'r', encoding='utf-8') as fd:
IOError: [Errno 2] No such file or directory:
'/Users/david/development/matplotlib/doc/mpl_examples/api/legend_demo.py'
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

I'll look into this now.
On Tue, Jul 15, 2014 at 11:43 AM, Lennart Fricke <le...@di...>
wrote:
>
> Hello,
>
> could somebody please check if the baseline_image is like it should be.
> During refactoring some of the linestyle handling, the test mentioned
> fails.
> And it seems to me, that the expected image is not correct.
>
> Best regards
> Lennart
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello, 
could somebody please check if the baseline_image is like it should be.
During refactoring some of the linestyle handling, the test mentioned
fails.
And it seems to me, that the expected image is not correct.
Best regards
Lennart

Hello, 
could somebody please check if the baseline_image is like it should be.
During refactoring some of the linestyle handling, the test mentioned
fails.
And it seems to me, that the expected image is not correct.
Best regards
Lennart

Wouldn't a better default be to just close all figures when they're
displayed? It can't be common that someone wants to show the same plot
repeatedly (and if they do that could have an option)...?
-n
On 14 Jul 2014 22:16, "Matthew Brett" <mat...@gm...> wrote:
> Hi,
>
> I am happily using `plot_directive`, but I've run into an
> inconvenience when using the 'context' option. Consider this rst
> file:
>
> ```
> #######
> A title
> #######
>
> .. plot::
> :context:
>
> import matplotlib.pyplot as plt
> plt.plot(range(10))
>
> Then some text.
>
> .. plot::
> :context:
>
> plt.figure()
> plt.plot(range(5), 'r')
> ```
>
> In the second panel you see plots for both the first figure and the
> second figure, because the underlying code is making this call:
>
> fig_managers = _pylab_helpers.Gcf.get_all_fig_managers()
>
> to find all current figures, finding the first and the second figure,
> and rendering both. I think this is unlikely to be what the user
> expects (it confused me), but I wasn't sure what the best way to work
> round it was. I considered adding another option like `:myfigs: true`
> to the directive which would only pick up figures I create using the
> current code block - is there a better way?
>
> Cheers,
>
> Matthew
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
I am happily using `plot_directive`, but I've run into an
inconvenience when using the 'context' option. Consider this rst
file:
```
#######
A title
#######
.. plot::
 :context:
 import matplotlib.pyplot as plt
 plt.plot(range(10))
Then some text.
.. plot::
 :context:
 plt.figure()
 plt.plot(range(5), 'r')
```
In the second panel you see plots for both the first figure and the
second figure, because the underlying code is making this call:
 fig_managers = _pylab_helpers.Gcf.get_all_fig_managers()
to find all current figures, finding the first and the second figure,
and rendering both. I think this is unlikely to be what the user
expects (it confused me), but I wasn't sure what the best way to work
round it was. I considered adding another option like `:myfigs: true`
to the directive which would only pick up figures I create using the
current code block - is there a better way?
Cheers,
Matthew

On 14 July 2014 00:10, Damon McDougall <dam...@gm...> wrote:
> On Sun, Jul 13, 2014 at 12:27 AM, Eric Firing <ef...@ha...> wrote:
> > On 2014年07月12日, 7:20 PM, Thomas Caswell wrote:
> >> Hey all,
> >>
> >> After a very productive sprint at scipy (according to pluse, we merged
> >> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
> >> the first release candidate (1.4.0rc1).
> >>
> >> There are a good number of outstanding issues with documentation (re
> >> the fate of pylab and installation) and one small issue with data
> >> cleaning in boxplots.
> >>
> >> I proposing giving our selves a 2 week deadline to have everything
> finalized.
> >>
> >> Tom
> >>
> >
> > Excellent! Thanks very much for keeping on top of all this, and for the
> > amazing amount of work you have been doing.
>
> I echo Eric's comments.
>
> Fantastic job, Thomas.
>
And very much appreciated!
N
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck&#174;
> Code Sight&#153; - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Jul 13, 2014 at 12:27 AM, Eric Firing <ef...@ha...> wrote:
> On 2014年07月12日, 7:20 PM, Thomas Caswell wrote:
>> Hey all,
>>
>> After a very productive sprint at scipy (according to pluse, we merged
>> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
>> the first release candidate (1.4.0rc1).
>>
>> There are a good number of outstanding issues with documentation (re
>> the fate of pylab and installation) and one small issue with data
>> cleaning in boxplots.
>>
>> I proposing giving our selves a 2 week deadline to have everything finalized.
>>
>> Tom
>>
>
> Excellent! Thanks very much for keeping on top of all this, and for the
> amazing amount of work you have been doing.
I echo Eric's comments.
Fantastic job, Thomas.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 2014年07月12日, 7:20 PM, Thomas Caswell wrote:
> Hey all,
>
> After a very productive sprint at scipy (according to pluse, we merged
> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
> the first release candidate (1.4.0rc1).
>
> There are a good number of outstanding issues with documentation (re
> the fate of pylab and installation) and one small issue with data
> cleaning in boxplots.
>
> I proposing giving our selves a 2 week deadline to have everything finalized.
>
> Tom
>
Excellent! Thanks very much for keeping on top of all this, and for the 
amazing amount of work you have been doing.
Eric

Hey all,
After a very productive sprint at scipy (according to pluse, we merged
35 PRs in the last 3 days), I have created the 1.4.x branch and tagged
the first release candidate (1.4.0rc1).
There are a good number of outstanding issues with documentation (re
the fate of pylab and installation) and one small issue with data
cleaning in boxplots.
I proposing giving our selves a 2 week deadline to have everything finalized.
Tom
-- 
Thomas Caswell
tca...@gm...

I am currently working on a PR for mplot3d that is also release critical
because there is something broken with the API. I hope to have it sorted
out in the next hour or two.
On Sat, Jul 12, 2014 at 9:45 AM, Nelle Varoquaux <nel...@gm...>
wrote:
> Hi everyone!
> I'm currently reviewing PR critical for 1.4: can people make sure to tag
> those as release_critical? There is only two open right now.
> Cheers,
> N
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi everyone!
I'm currently reviewing PR critical for 1.4: can people make sure to tag
those as release_critical? There is only two open right now.
Cheers,
N

I wonder if the tick marks could take advantage of advantages of
Line2DCollection (if it hasn't already), or maybe go so far as to have them
be PatchCollections? We could maintain full feature set and such, but take
advantage of some of the optimized rendering pathways in the backends that
were originally made for plot()?
Just thinking off the top of my head at the moment.
Cheers!
Ben Root
On Wed, Jul 9, 2014 at 12:54 PM, Joel B. Mohler <jo...@ki...>
wrote:
> On 07/08/2014 11:33 AM, Bartosz wrote:
> > Hi,
> >
> > When improving the performance of plotting high-dimensional data using
> > faceted scatter plots, I noticed that much of time was spent on the axis
> > creation (even 50%!).
> >
> > On my machine creating 20x20 array of subplots without actually plotting
> > anything takes about 11 seconds (for comparison plotting 5000 points on
> > all of them takes only 0.6s!):
> >
> > import matplotlib
> > matplotlib.interactive(True)
> > import matplotlib.pyplot as plt
> > fig, axes = plt.subplots(20,20)
> > plt.show()
> >
> > Profiling shows that 50% of computation time is spent on axis/ticks
> > creation [1], which I have to remove anyways. Is there any easy way of
> > creating thinned axes without ticks and spines?
> >
> > So far I solved the problem by subclassing Axes class (see this gist
> > [2]) and removing all spines and ticks. Running the above example gives
> > a 10x boost in performance (from 11s to 0.9s).
> >
> > import thin_axes
> > fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
> > plt.show()
>
> Hi, I also have found tick marks to be a real performance drain and am
> trying to fix this. I have yet to get my ideas all in a shape which is
> worthy of a pull request. It's a rather large change under the hood and
> so there are probably quite a few edge cases which I'm not really aware
> of since I'm sure I only care about 50% (or less) of the full range of
> flexibility. That said, simple graphs with basic tick marks are much
> slower than they need to be.
>
> My work is at https://github.com/jbmohler/mplfastaxes and I also used
> the custom projection method to replace the Axes/Axis classes. I have
> incorporated your example because I think it is interesting (even
> through 20x20 grid of axes seems crazy to me ... it may make sense
> though :) ).
>
> You have addressed a somewhat different case than myself because I've
> focused on the speed of drawing the graphics where-as your gist
> illustrates that making a new figure with many axes is very slow. I
> believe the same ideas apply and I'm going to spend some time right now
> improving my code's initialization which is basically unchanged from MPL
> at this point.
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 07/08/2014 11:33 AM, Bartosz wrote:
> Hi,
>
> When improving the performance of plotting high-dimensional data using
> faceted scatter plots, I noticed that much of time was spent on the axis
> creation (even 50%!).
>
> On my machine creating 20x20 array of subplots without actually plotting
> anything takes about 11 seconds (for comparison plotting 5000 points on
> all of them takes only 0.6s!):
>
> import matplotlib
> matplotlib.interactive(True)
> import matplotlib.pyplot as plt
> fig, axes = plt.subplots(20,20)
> plt.show()
>
> Profiling shows that 50% of computation time is spent on axis/ticks
> creation [1], which I have to remove anyways. Is there any easy way of
> creating thinned axes without ticks and spines?
>
> So far I solved the problem by subclassing Axes class (see this gist
> [2]) and removing all spines and ticks. Running the above example gives
> a 10x boost in performance (from 11s to 0.9s).
>
> import thin_axes
> fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
> plt.show()
Hi, I also have found tick marks to be a real performance drain and am 
trying to fix this. I have yet to get my ideas all in a shape which is 
worthy of a pull request. It's a rather large change under the hood and 
so there are probably quite a few edge cases which I'm not really aware 
of since I'm sure I only care about 50% (or less) of the full range of 
flexibility. That said, simple graphs with basic tick marks are much 
slower than they need to be.
My work is at https://github.com/jbmohler/mplfastaxes and I also used 
the custom projection method to replace the Axes/Axis classes. I have 
incorporated your example because I think it is interesting (even 
through 20x20 grid of axes seems crazy to me ... it may make sense 
though :) ).
You have addressed a somewhat different case than myself because I've 
focused on the speed of drawing the graphics where-as your gist 
illustrates that making a new figure with many axes is very slow. I 
believe the same ideas apply and I'm going to spend some time right now 
improving my code's initialization which is basically unchanged from MPL 
at this point.
Joel

Hi,
When improving the performance of plotting high-dimensional data using 
faceted scatter plots, I noticed that much of time was spent on the axis 
creation (even 50%!).
On my machine creating 20x20 array of subplots without actually plotting 
anything takes about 11 seconds (for comparison plotting 5000 points on 
all of them takes only 0.6s!):
import matplotlib
matplotlib.interactive(True)
import matplotlib.pyplot as plt
fig, axes = plt.subplots(20,20)
plt.show()
Profiling shows that 50% of computation time is spent on axis/ticks 
creation [1], which I have to remove anyways. Is there any easy way of 
creating thinned axes without ticks and spines?
So far I solved the problem by subclassing Axes class (see this gist 
[2]) and removing all spines and ticks. Running the above example gives 
a 10x boost in performance (from 11s to 0.9s).
import thin_axes
fig, axes = plt.subplots(20,20, subplot_kw=dict(projection='thin'))
plt.show()
Profiling results show more uniform distribution of computing time 
across functions (most time is spent on creating and applying transforms 
[3]).
The thinned class seems a bit hacky. Is there any other way to create a 
raw Axes object without spines, ticks, labels etc., just pure canvas 
with appropriate transforms?
Yours,
Bartosz
[1] profiling results of vanilla Axes: http://pbrd.co/1jlovoo
[2] https://gist.github.com/btel/a6b97e50e0f26a1a5eaa
[3] profiling results of thined Axes:

Hi there,
I might have found a bug which seems fixed by the attached patch.
The bug is in the FancyBBoxPatch class, which I encountered unsuccessfully 
trying to minimize the padding of a fancy box around a small text.
In lieu of a testcase I submit the skeleton of a command causing troubles:
 plt.annotate('{0}%'.format(100),xytext=(1,1),xy=(2,2),
 arrowprops=dict(arrowstyle='->',
 connectionstyle=connstyle,
 color='b'
 ),
 bbox=dict(facecolor='white',boxstyle='round',bounds=(1,1,1,1)),
 color='b')
I can;t now recall the bug and I shifted away from FancyBBox and trying to 
minimize the padding. In any case, I hope it helps.
Regards,
Janis

Hey,
An update on the status of getting 1.4.0 out the door. By my count we
have 14 patches that need review and 4 issues that need patches. It
looks like we will miss getting it tagged before scipy, but I really
hope we can at least tag and announce a rc during it.
I see that there is a MEP BoF already schedule for scipy, are sprints
formally organized or ad-hoc?
need review:
#3190 : two new style sheets. Given that style sheets are one of the
cool new features in 1.4, I think merging these is a good idea, but
want to make sure others agree
#3188 : fixes up bugs exposed by changing behavior in numpy. They are
changing those errors to warnings before they tag 1.9 so not urgent
#3184 : DOC added text warning to `get_window_extent` that it can take
your foot off
#3174 : fixes api break added with qt5, RELEASE CRITICAL
#3170 : a lot of changes to the FAQs, will probably need discussion at scipy
#3167 : adds error checking to `plt.subplot` and company
#3165 : restores defaults to boxplot, RELEASE CRITICAL
#3156 : DOC for adding qt5
#3121 : tweaks to rcparam for qt backends
#3112 : fixes bug in wedge. (I really want this merged for my day job)
#2952 : turn clipping off on all objects in pie charts
#2951 : changes in AnchoredSizeBar api.
#2843 : fixes the labels added to contour plots. It works, but could
use more internal documentation RELEASE CRITICAL
needs revision:
#2742 : add documentation about how to rebase (which is my problem,
this might get punted)
NEEDS PATCH:
#3126 : something is not right with how the the annotate docstrings
get parsed by sphinx
#3090 : proposal do stop testing 3.2 (which more-or-less drops
official support for it), easy to do but needs consensus to do it
#2999 : install docs for windows/mac, should be done by who ever
packages up the release for those platforms
#2903 : the plot directive is not always working correctly, some of
the links are screwy
Tom
-- 
Thomas Caswell
tca...@gm...