-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Scipy 2013 BOF Notes
The original notes were taken on etherpad. @mdboom has reorganized them and summarized them here.
-
Interactive modification of plots would address the issues on tweaking commented on at the plotting competition
-
Need a way to write out the tweaks "as code" afterward to paste back into a script (or into the IPython notebook)
-
Igor Pro has a good track record of having 1-1 correspondence between image and code
-
Veusz can also produce code from a manually tweaked plot
-
vispy: High performance plotting project (in early days)
-
We should create a MEP on openGL (and more generally for high performance plotting)
-
An analysis of performance bottlenecks should be done, perhaps a standard set of benchmarks to track over time (#2188)
-
in general, this kind of a benchmarking of the fall-off of performance would be useful to point users to.
-
Experiment with reducing quality during panning/zooming, and then going back to full quality on idle (much like older 3D packages used to show only a bounding box during rotation). (#2189)
-
-
We should add built-in instrumentation of matplotlib methods -- this would allow us to collect statistics about performance as well as more easily help users debug problems when they are hard to reproduce. (#2190)
-
Use something we either rent or control instead of travis in order to collect more data on different platforms.
-
We need a larger test matrix -- Python, Numpy, GUI framework, Freetype and libpng versions. From this we can keep on top of our version requirements.
-
In a follow-up breakout session, we thought the minimum requirements would be:
-
Mac and Linux virtual machines that a number of core developers can log into
-
Windows virtual machines if feasible
-
Github integration (like what Travis does)
-
The ability for other machines with different configurations to publish their results to a public web server
-
Saving the output of the tests
-
Saving build products ("daily", or more often)
-
Auto-building the docs
-
-
We have Launchpad daily builds https://code.launchpad.net/~takluyver/+recipe/matplotlib-daily
-
use notebook output and potentially store the output in the notebook to store the image output in the repo
-
have an interactive plotting documentation system in which you can edit plots online (Google App engine)
-
Enthought uses the casuarius constraint solver for their (Enaml)[http://docs.enthought.com/enaml/index.html] layout engine -- steal or borrow?
-
Tight-layout goes a long way already - thank you jae-joon
-
See #1109 for earlier (and continued) discussion
-
There is disagreement about whether constrained layout and plot editor are orthogonal and whether we could pursue both in parallel or should pick one or the other as a focus
We should revive this.
-
Plot method could take "plottable" objects (rather than just Numpy arrays), and those objects could obtain or generate data in other ways (such as for functional plotting)
-
This lead to a discussion about 2.0 (i.e. breaking some backward compatibility). However, it was noted that we were a room full of developers, not users.
- We should keep track of the versions of Numpy and other dependencies in the major long-term-release Linux distributions (Debian, RedHat, Ubuntu) and ensure (probably though better CI) that we continue to support them. (#2191) The census (above) may help us with this kind of thing as well.