[matplotlib-devel] Mixed-mode rendering
Hi,
On trunk, there is mixed-mode rendering support built in to (at least) the
SVG and PDF backends, though there are no calls to start/stop_rasterizing()
that utilize the raster mode. I've implemented mode switching for
those backends,
and would appreciate feedback on what I've done.
There are two modes that might drive a switch to raster for some artists:
1. User-driven specification of known complex artitsts.
2. Automatic detection of artist complexity (by type or vertex count).
The first mode is what I coded up, so I'll discuss it below.
A list of artists to rasterize is passed as a draw_raster kwarg to savefig,
which percolates down into print_* in the backend-specific figure canvas.
When the backend's canvas creates a renderer, the draw_raster list is placed
as an attribute on the renderer instance. I figured that the renderer should
be responsible for transporting the list of artists needing rasterization,
since it's at the renderer level that pixel vs. vector matters.
The switch to/from raster mode was made in Axes.draw, where the artists for
each axes are looped over. In the artist loop, I check if the artist to be
rendered is listed in the draw_raster attribute on the renderer instance. If
so, the appropriate calls are made to start and stop rasterizing.
Sample usage:
f=pyplot.figure()
ax=f.add_subplot(111)
p,=ax.plot(range(10))
f.savefig('test.pdf', draw_raster=(p,))
svn diff at
http://www.deeplycloudy.com/20080503-matplotlib-mixed-mode-r5110.diff
Thanks,
Eric Bruning
Graduate Research Assistant, Meteorology, Univ. Oklahoma
As of 6/1/2008, Research Assoc., Univ. Maryland/CICS and NOAA/NESDIS/STAR
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] TextCollection
On Jul 22, 2008, at 6:26 PM, Ryan May [EMAIL PROTECTED] wrote: John Hunter wrote: On Mon, Jul 21, 2008 at 11:35 PM, Ryan May [EMAIL PROTECTED] wrote: Hi, Has anyone ever thought about creating a TextCollection class? The purpose would be similar to the other collections, to group a bunch of text objects with similar properties. This probably couldn't inherit from Collection as of now though, since Collection assumes things like edgecolor and facecolor. The bigger question to me is, could the backends make use of this to any improvement? Or would this simply serve as an API to eliminate having to loop yourself (which would pretty much make this useless). My own personal use case is (once again) in meteorology, where we do station plots. This involves printing the actual value of observed variables relative to the location of the station. This isn't hard to do right now (especially since I have offset_copy back, thanks Mike!). I just wasn't sure if the batch functionality of a Collection might serve some purpose to the users at large. I've thought of it many times and it would definitely be useful, eg for tick labels. Treating every label as a separate instance definitely slows things down. Ok, good to know. I'll put it on my todo list then. Do you think this can inherit from Collection at all? It seemed like a lot of the methods in the Collection base class were specific to polygons or other geometry and don't really make sense in the case of text. - There's some precedent for treating text as a collection of paths; for instance, many eps exporters allow 'as path' or 'as text' as options. I think most vector drawing apps treat the text color as a face color, and support an additional edge color for doing outline effects. So on that conceptual basis a collection seems appropriate, even if the renderer treats it differently than a polygon. -Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scale independent drawing
On Tue, Jul 22, 2008 at 6:55 PM, Eric Firing [EMAIL PROTECTED] wrote: Ryan May wrote: Hi, I'll continue my current flood of emails to the list. :) I'm finally getting back to my work on Skew-T plots, and I have a semi-working implementation (attached.) It runs, and as is, plots up some of the grid, with the x-value grid lines skewed 45 degrees to the right (as they should be.) The problem is as you resize the plot horizontally, some weird things happen. First, some of the lines that start overlaid end up separating as you expand the plot. The difference is between what is added using ax.plot and what is added using ax.vlines. The former adds Line2D objects while the latter adds a LineCollection which is holding path objects. I'm really not sure what's going on there. I'm not done checking it out yet, but I'm curious if anyone has any ideas off the top of their head. The second issue, which is more pressing, is when you resize vertically, the axes limits of the plot don't change (good), but unfortunately the lines don't stay connected to their lower y-coordinate in data space (bad). I'm really needing to draw things in a coordinate system that's independant of the data scale but also doesn't depend on the aspect ratio of the axes, so that I can get lines (and data plots) where the x gridlines are always at a 45 degree angle and the lower Y-value point stays fixed. By problem right now is that while I can find the lower left corner in pixel space and use that to do the proper adjustments, this changes when you resize. This changing is especially important in the y-direction. What I need is either of: 1) Axes space adjusted for aspect ratio (and updated with resizes) 2) Pixel space relative to some corner of the axes Or something similar that I don't know about. Any thoughts, or do I just need to come up with some magical combination of transforms that works? You can see what I have so far in my attached file. Ryan, based only on your description of the problems, and of what you need, I think the answer, or at least part of it, may be in good old quiver. Look at the way the transform is being generated depending on the units chosen, and note that preserving a specified angle on the page is part of it. Also note that the transform has to be regenerated on resize events, so a custom draw method is required. (Mike D. translated my original quiver code to use his transforms framework.) It seems like there should be an easier-to-use and more general way to do these sorts of things, and maybe there is--or maybe it can be ginned up. This reminds me of a thread a long time ago regarding adding hooks so that classes could register methods to be executed before their artists are rendered but after things like window and axes sizes have been determined. Since I'm 1. A meteorologist and 2. responsible for the draw-hook thread, I see I'm implicated here :) The utility of the before/after draw hook comes in when you want to do something system wide on all draw events. If the SkewT needs to do some setup before the Axes draw, a simple override of draw() seems the better route, since the need here would be class specific. That said, I was inspired by this to add on a bit to my previous hook solution, but that belongs in a separate thread. -Eric B - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Before/after callback registry decorator
I've expanded a bit on my previous solution for pre/post draw method
callbacks to add a registry which can be used to connect up arbitrary
callback functions.
The solution above is easy to adapt to other functions that might need
a callback, such as (to pick a random example) set_xlim.
See the attached example, which shows the functionality in action.
I've also shown how to handle the calls to start/stop raster in the
renderer that were my previous use case.
-Eric B
from matplotlib.cbook import CallbackRegistry
from matplotlib.axes import Axes
class Hooks(object):
def __init__(self):
signals = ('before_draw', 'after_draw')
self.callbacks = CallbackRegistry(signals)
def before_after_draw(self, draw):
Decorator for Artist.draw method. Provides routines
that run before and after the draw call. The before and after functions
are useful for changing artist-dependant renderer attributes or making
other setup function calls, such as starting and flushing a mixed-mode
renderer.
def before(artist, renderer):
self.callbacks.process('before_draw', artist, renderer)
def after(artist, renderer):
self.callbacks.process('after_draw', artist, renderer)
def draw_wrapper(artist, renderer):
before(artist, renderer)
draw(artist, renderer)
after(artist, renderer)
# safe wrapping to exactly replicate anything we haven't overridden above
draw_wrapper.__name__ = draw.__name__
draw_wrapper.__dict__ = draw.__dict__
draw_wrapper.__doc__ = draw.__doc__
return draw_wrapper
def greeter(artist, renderer):
print 'Hello, ', artist, '. You will be rendered tonight by', renderer
def benediction(artist, renderer):
print 'Good night, ', artist, '. You were rendered tonight by', renderer
def start_raster_mode(artist, renderer):
if artist.get_rasterized():
renderer.start_rasterizing()
def stop_raster_mode(artist, renderer):
if artist.get_rasterized():
renderer.stop_rasterizing()
hooks = Hooks()
hooks.callbacks.connect('before_draw', greeter)
hooks.callbacks.connect('after_draw', benediction)
hooks.callbacks.connect('before_draw', start_raster_mode)
hooks.callbacks.connect('after_draw', stop_raster_mode)
class WrappedAxes(Axes):
In real life, the Axes.draw() method would be decorated directly,
but this serves for the purposes of this demo.
@hooks.before_after_draw
def draw(self, renderer):
super(WrappedAxes, self).draw(renderer)
import matplotlib.pyplot as plt
fig = plt.figure()
fig.clf()
ax = fig.add_axes(WrappedAxes(fig, (0.1,0.1,0.8,0.8)))
ax.plot(range(10))
plt.show()
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Alternate lasso: click to form polygon
I wanted something more precise (and easier on the carpal tunnel) than
the included Lasso widget. Inspired by the existing Lasso, I forked
out an alternate approach that creates a polygon with mouse clicks and
returns a list of vertices to a callback function.
See the attached for a demo. It's been tested with WxAgg running off
recent svn. I'm using idle_event, which isn't mentioned in the docs
for the released version.
If there's interest, I'll put together a patch to add this to widgets.py.
Thanks,
Eric B
from matplotlib.lines import Line2D
from matplotlib.widgets import Widget
class PolyLasso(Widget):
A lasso widget that allows the user to define a lasso region by
clicking to form a polygon.
def __init__(self, ax, callback=None,
line_to_next=True,
useblit=True):
Create a new lasso.
*ax* is the axis on which to draw
*callback* is a function that will be called with arguments (*ax*, *line*, *verts*).
*verts* is a list of (x,y) pairs that define the polygon, with the first and
last entries equal.
*line_to_next* controls whether or not a line is drawn to the current
cursor position as the polygon is created
*useblit* = *True* is the only thorougly tested option.
self.axes = ax
self.figure = ax.figure
self.canvas = self.figure.canvas
self.useblit = useblit
self.line_to_next = line_to_next
if useblit:
self.background = self.canvas.copy_from_bbox(self.axes.bbox)
self.verts = []
self.line = None
self.callback = callback
self.cids = []
self.cids.append(self.canvas.mpl_connect('button_release_event', self.onrelease))
self.cids.append(self.canvas.mpl_connect('motion_notify_event', self.onmove))
self.cids.append(self.canvas.mpl_connect('draw_event', self.ondraw))
def ondraw(self, event):
draw_event callback, to take care of some blit artifacts
self.background = self.canvas.copy_from_bbox(self.axes.bbox)
if self.line:
self.axes.draw_artist(self.line)
self.canvas.blit(self.axes.bbox)
def do_callback(self, event):
idle_event callback after polygon is finalized.
# Clear out callbacks.
for cid in self.cids:
self.canvas.mpl_disconnect(cid)
self.callback(self.axes, self.line, self.verts)
self.cleanup()
def cleanup(self):
Remove the lasso line.
# Clear out callbacks
for cid in self.cids:
self.canvas.mpl_disconnect(cid)
self.axes.lines.remove(self.line)
self.canvas.draw()
def finalize(self):
Called when user makes the final right click
# all done with callbacks pertaining to adding verts to the polygon
for cid in self.cids:
self.canvas.mpl_disconnect(cid)
self.cids = []
# Greater than three verts, since a triangle
# has a duplicate point to close the poly.
if len(self.verts)3:
# Matplotlib will not draw the closed polygon until we step completely
# out of this routine. It is desirable to see the closed polygon on screen
# in the event that *callback* takes a long time. So, delay callback until
# we get an idle event, which will signal that the closed polygon has also
# been drawn.
self.cids.append(self.canvas.mpl_connect('idle_event', self.do_callback))
else:
print 'Need at least three vertices to make a polygon'
self.cleanup()
def draw_update(self):
Adjust the polygon line, and blit it to the screen
self.line.set_data(zip(*self.verts))
if self.useblit:
self.canvas.restore_region(self.background)
self.axes.draw_artist(self.line)
self.canvas.blit(self.axes.bbox)
else:
self.canvas.draw_idle()
def onmove(self, event):
Update the next vertex position
if self.line == None: return
self.verts[-1] = ((event.xdata, event.ydata))
if self.line_to_next:
self.draw_update()
def onrelease(self, event):
User clicked the mouse. Add a vertex or finalize depending on mouse button.
if self.verts is None: return
if event.inaxes != self.axes: return
if event.button == 3:
# Right click - close the polygon
# Set the dummy point to the first point
self.verts[-1] = self.verts[0]
self.draw_update()
self.finalize()
return
# The rest pertains to left click only
if event.button != 1: return
if self.line == None:
# Deal with the first
Re: [matplotlib-devel] Native backend for Mac OS X
Nice work ... and an ambitious effort.
I've gotten it running, and am a bit perplexed by some of the
performance I'm seeing. Specifically, the following bit takes well
over twice as long to run as does WxAgg. Does this align with others'
testing?
The only difference I detect is that the Mac backend puts up a window
on the call to plt.figure, while WxAgg waits until the call to show().
Thanks,
Eric
# for testing macosx backend only
import matplotlib
matplotlib.use('macosx')
import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(1e4)
y=np.sin(x)
ax=f.add_subplot(111)
sc=ax.scatter(x,y,c=x**2.0)
plt.show()
On Tue, Oct 28, 2008 at 12:13 PM, Christopher Barker
[EMAIL PROTECTED] wrote:
Michiel de Hoon wrote:
I wrote a backend for matplotlib on Mac OS X. This is a native
backend for Mac OS X
very nice!
4) One drawback compared to the existing cocoa-agg backend is that
the latter allows easy integration of matplotlib into a larger cocoa
application, whereas my backend only cares about matplotlib.
well, as far as many of us are concerned, matplotlib IS an embeddable
plotting package. I suppose you could say that your backend only cares
about pylab.
Is there any possibility to embed it in another app? I know that wx, for
instance, can pass a Window handle to other libs, so that you can have
that window managed and drawn by other code, while wx handles the rest
of the app -- would this kind of thing be possible with your code with
wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it
is using X11, though I suppose if you are using Apple's X11, it could
even be possible there.
Whereas matplotlib has a vastly superior range of high-level plotting
capabilities, pygist excelled at sheer speed. This was achieved by
having three backends (Windows, Mac OS X, X11) written in C for
optimal performance,
I'm still curious where all this speed comes from. MPL already uses Agg
for a lot, and it's generally reported to be as fast as many native
drawing APIs (though maybe not quartz?)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SVG clickable images
Another use case in favor of implementation of the URL property at the
artist level:
Consider a map with scatter points representing geolocated photos that
can be viewed at some URL. Attach a mouse click on the artist to the
following code:
import webbrowser
webbrowser.open(patch.url)
And you have an interactive map that lets you grab remote data.
-Eric
On Thu, Oct 30, 2008 at 10:02 AM, John Hunter [EMAIL PROTECTED] wrote:
On Thu, Oct 30, 2008 at 8:10 AM, Michael Droettboom [EMAIL PROTECTED] wrote:
In the specific case of bar(), one may still be forced to manually set
urls on each Rectangle if one wants those urls to be different. But
this is no different than the current situation wrt facecolor or any
other attribute, since bar is not written on top of Collection.
better yet would be to replace the list of rectangles with a patch
collection, do the same for pie, etc. Then a single URL on the
collection would apply to the batch. This would break a fair amount
of code, but we might be able to minimize the pain by providing an
iter interface and a getitem interface to the collection, which warns
and does the right thing. So users who did
# bars was a list of Rectangles, now it is a PatchCollection
for bar in bars:
bar.set_facecolor('red')
would get working code and a warning telling them to just do
bars.set_facecolors instead.
And, yes, the example is *very cool*
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Loss of filled vs. stroked distinction by Collections
I think of artists as having visual properties that persist (e.g., filled vs. outlined, a colormap with min and max values) even as data associated with the artist is changed. In the edge case described below, this doesn't seem to hold true. I have code that animates a scatter plot by sub-selecting the data stored in a collection artist. In cases where some frames contain no data, the scatter artist's data is temporarily empty. On subsequent frames (once there is data again) some of the visual properties my filled point becomes an outlined point, as in the code below. # Filled single point with no outline sc = scatter([1],[1],c=[1], edgecolors='none') # Cache the data xy=sc.get_offsets() s=sc.get_array() sel=s0 sc.set_offsets(xy[sel,:]) sc.set_array(s[sel]) # No data, so nothing shown. No problem. sc.figure.canvas.draw() # Now restore the original data sc.set_offsets(xy) sc.set_array(s) # Outlined single point with no fill sc.figure.canvas.draw() sc.get_edgecolors() sc.get_facecolors() sc.get_array() The fix probably has to do with Collection.update_scalarmappable. When set_array([ ]) happens, len(self._facecolors) 0, therefore self._facecolors = to_rgba([ ]), When set_array([1]) restores data, len(self._facecolors) == 0, therefore self._edgecolors = self.to_rgba([1]) Should is_filled vs. is_stroked be preserved in this case? If so, is there a more elegant fix than to add is_filled and is_stroked properties that are checked by update_scalarmappable? Thanks, Eric -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Loss of filled vs. stroked distinction by Collections
Thanks for the fix - works for me on this afternoon's SVN. -Eric On Mon, Dec 15, 2008 at 1:27 AM, Eric Firing efir...@hawaii.edu wrote: Eric Bruning wrote: I think of artists as having visual properties that persist (e.g., filled vs. outlined, a colormap with min and max values) even as data associated with the artist is changed. In the edge case described below, this doesn't seem to hold true. I have code that animates a scatter plot by sub-selecting the data stored in a collection artist. In cases where some frames contain no data, the scatter artist's data is temporarily empty. On subsequent frames (once there is data again) some of the visual properties my filled point becomes an outlined point, as in the code below. # Filled single point with no outline sc = scatter([1],[1],c=[1], edgecolors='none') # Cache the data xy=sc.get_offsets() s=sc.get_array() sel=s0 sc.set_offsets(xy[sel,:]) sc.set_array(s[sel]) # No data, so nothing shown. No problem. sc.figure.canvas.draw() # Now restore the original data sc.set_offsets(xy) sc.set_array(s) # Outlined single point with no fill sc.figure.canvas.draw() sc.get_edgecolors() sc.get_facecolors() sc.get_array() The fix probably has to do with Collection.update_scalarmappable. When set_array([ ]) happens, len(self._facecolors) 0, therefore self._facecolors = to_rgba([ ]), When set_array([1]) restores data, len(self._facecolors) == 0, therefore self._edgecolors = self.to_rgba([1]) Should is_filled vs. is_stroked be preserved in this case? If so, is there a more elegant fix than to add is_filled and is_stroked properties that are checked by update_scalarmappable? I don't see a better way, so I implemented your suggestion. Eric -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Hi Michiel, +1 to Chris Barker's request for information on where Agg makes extra calls to draw(). The 20% speedup in scatter performance is nice, and is clearly related to Agg. Any idea why the pcolormesh example is so much slower in Mac OS X than TkAgg? Thanks for your continued work on this. -Eric On Wed, Dec 17, 2008 at 5:52 AM, John Hunter jdh2...@gmail.com wrote: Hi Michiel, This looks great -- in particular I am intrigued by the final timing results which show your backend 12 times faster than tkagg. I am not sure where this speedup is coming from -- do you have some ideas? Because you are creating lots-o-subplots in that example, there is a lot of overhead at the python layer (many axes, many ticks, etc) so I don't see how a faster backend could generate such a significant improvement. What kind of timings do you see if you issue a plot rather than bar call in that example? One thing about bar in particular is that we draw lots of separate rectangles, each with thie own gc, and it has been on my wishlist for some time to do this as a collection. If you are handling gc creation, etc, in C, that may account for a big part of the difference. Since the new macosx backend was released in 0.98.5, I also need to decide whether this patch belongs on the branch, and hence will get pushed out as early as today in a bugfix release when some changes JJ and Michael are working on are ready, or the trunk, in which case it could be months. In favor of the trunk: this is more of a feature enhancement than a bugfix, and patches to the branch should be bugfixes with an eye to stability of the released code, though a good argument could be made that this is a bugfix. In favor of the branch: it is brand new code advertised as beta in 0.98.5 and so it is unlikely that anyone is using it seriously yet, and since it is beta, we should get as much of it out there ASAP so folks can test and pound on it. I'm in favor of branch, but I wanted to bring this up here since we are fairly new to the branch/trunk release maintenance game and want to get some input and provide some color about which patches should go where, especially in gray areas like this. JDH On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon mjldeh...@yahoo.com wrote: Dear all, I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at http://sourceforge.net/tracker/?func=detailatid=560722aid=2179017group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below). # Timings in seconds # n Mac OS X TkAgg # 2 2 6 # 3 3 23 # 4 5 66 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Rasterized artists have wrong transform
I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.
Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?
Thanks,
Eric
Sample code to reproduce the problem:
import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] File format for plots
One of the mpl backends is svg; can you use something like Inkscape to make the plot adjustments you are talking about? Eric [F] I'll second this recommendation - indeed, it's my default workflow (except that I use Illustrator). By definition, vector image formats contain all the data needed to (re)make the plot. Everything can be rescaled, line weights changed, colors modified, etc. -Eric B -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
Hi Jae-Joon,
On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote:
Hi Eric,
Have you find a solution for your problem?
I recently encountered a similar problem.
In my case, the images (I'm rasterizing the pcolormesh) are in wrong
size if the output dpi is other than 72.
And I guess this is related with the changes Jouni made in revision 6730.
So, can you see if you have a correct output with dpi=72?
If that's the case, can you try the attached patch and see if it
solves your problem (should work with dpi other than 72).
I hadn't found a solution (other than rendering to svg), so thanks for
waking up this thread. I can confirm that I get the correct output
when I set dpi=72.
I don't quite like my solution but it seems to work.
It passes over the figure instance when initializing the
MixedRenderer, and let the renderer change the dpi of the figure when
changing the backend.
I hope some other developer who better understands the dpi thing take
a look and come up with a better solution.
I'll try to take a look at this later this afternoon. I agree that
someone with more knowledge should take a look. The SVG backend seems
to just ignore the dpi setting and forces 72 dpi across the board,
which is why I was able to use it as a workaround.
Thanks,
Eric
Regards,
-JJ
On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning eric.brun...@gmail.com wrote:
I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.
Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?
Thanks,
Eric
Sample code to reproduce the problem:
import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
I don't quite like my solution but it seems to work. It passes over the figure instance when initializing the MixedRenderer, and let the renderer change the dpi of the figure when changing the backend. I hope some other developer who better understands the dpi thing take a look and come up with a better solution. I'll try to take a look at this later this afternoon. I agree that someone with more knowledge should take a look. The SVG backend seems to just ignore the dpi setting and forces 72 dpi across the board, which is why I was able to use it as a workaround. I applied your patch, and it does allow the PDF backend to produced mixed modes at various DPI. The SVG backend complains about the change in call signature to MixedModeRenderer.__init__(). SVG is the only other backend to use MixedModeRenderer, so that would be an easy fix. It seems surprising that dpi=72 is part of the renderer assumptions somewhere along the way. From a design perspective, is it appropriate for the renderer to store a reference to a figure? Many (all?) of the renderers seem entirely decoupled from the figure. -Eric -Eric -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
The idea of a shell with inline plots is a fascinating one - I like the minimalism and directness of being able to plot data like this. And the speed of OpenGL is obviously attractive. Is the figure() call syntax different from the existing syntax for figure()? I think there's a usage pattern ingrained in my head that says 'figure = new window,' and any change to the call syntax for figure would seem to open up a lot of room for confusion. It seems that the backend and the shell might be separate issues? My view of the backends is that they only deal with knowing how to draw artists, and are separate from the process of creating those artists through an interactive shell. The following old thread is also relevant, which you may have already seen: http://www.nabble.com/opengl-backend-td19192625.html Thanks, Eric B On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier nicolas.roug...@loria.fr wrote: Hello, While looking at possible solutions for a matplotlib OpenGL backend, I've been experimenting with pyglet (that has no dependencies) and coded a terminal with embedded 2d arrays display. Sources screenshots are available at: http://www.loria.fr/~rougier/glnumpy.html Since pyglet seems mature enough, I would like to know if anyone interested in helping writing the OpenGL backend (using pyglet) ? Nicolas -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
On Thu, Apr 16, 2009 at 1:38 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Eric and others, I just committed the fix for this problem to the trunk. It should also work with the svg backend. Thanks, that's fantastic. I'm glad to have the fix in place. On a somewhat related note, how are you turning rasterization on and off? Are you using my per-artist patch (which last I knew wasn't in trunk) or some other solution? From a design perspective, is it appropriate for the renderer to store a reference to a figure? Many (all?) of the renderers seem entirely decoupled from the figure. I acknowledge this issue but I couldn't find a better solution, so I hope someone else come up with a better idea. It's easy for me to critique, but you actually wrote some code :) Thanks, Eric -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning eric.brun...@gmail.com wrote: On a somewhat related note, how are you turning rasterization on and off? Are you using my per-artist patch (which last I knew wasn't in trunk) or some other solution? I remember that I tried to use your patch, but all the links that I found were broken. So I wrote a few lines for monkey patching. It was straight forward as I only needed a rasterization of the QuadMesh class. Sorry about the broken links. I've attached a diff made against trunk from a few days ago. The discussion about what to do with my patch fizzled. I created a decorator that made mixed-mode switching a one-line change per artist type. I also added get/set_rasterized and an _rasterized attribute to the Artist base class. I've used it on and off for a few months now with no noted bugs. If we don't like the decorator, we can just make a helper function that is called at the beginning of every artist.draw() method. It's not a very complicated modification. Are you planning to commit your patch to the trunk? I'll be glad to help you if there are any issues. I'd love to get the patch in trunk, if only so that more people can try it out and find things to improve (or re-implement). Thanks, Eric mixed-mode.diff Description: Binary data -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
The discussion about what to do with my patch fizzled. I created a decorator that made mixed-mode switching a one-line change per artist type. I also added get/set_rasterized and an _rasterized attribute to the Artist base class. I've used it on and off for a few months now with no noted bugs. If we don't like the decorator, we can just make a helper function that is called at the beginning of every artist.draw() method. It's not a very complicated modification. Would there be a case that draw methods of some Artists do not need to be decorated? Not that I can think of, if rasterization defaults to off and it's a user setting to turn it on (except perhaps some future modification where we auto-detect egregious poly counts in a mesh, for instance). If not, I guess some metaclass black magic might be not harmful. What do you think? I'm attaching modified version of your patch which utilize metaclass for decoration. I like that this solution doesn't litter every call to draw with rasterize checks. But it means that the rasterization support had better be robust, since Artist authors might not know they're interacting with the rasterization code. It has the downside of being implicit rather than explicit. I personally want that rasterization is also supported in the ps backend. I guess the missing support of alpha composition would be a problem. But, in most of the my use case, I want rasterization for artist with z lower than some specified value (i.e., background images using pcolormesh), so it is not a problem for me. I'm not too familiar with the PS backend, but I think that's separate from the issue of how to tell the renderer when to rasterize. Thanks, Eric Are you planning to commit your patch to the trunk? I'll be glad to help you if there are any issues. I'd love to get the patch in trunk, if only so that more people can try it out and find things to improve (or re-implement). Thanks, Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing efir...@hawaii.edu wrote: Jae-Joon Lee wrote: On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning eric.brun...@gmail.com wrote: I like that this solution doesn't litter every call to draw with rasterize checks. But it means that the rasterization support had better be robust, since Artist authors might not know they're interacting with the rasterization code. It has the downside of being implicit rather than explicit. Eric, I think we'd better stick to your decorator solution. Anyhow, I thought you had a svn commit permission but it seems not. Do you (and other dwevelopers) mind if I commit this patch to the trunk? It would be especially good for John and Mike to have a look. As a matter of style, I suggest a name change. @hook_before_after_draw is too generic, and brings to mind discussions a long time ago about possibly adding a general hook mechanism; even before rasterization, and before decorators were available, there were thoughts that we might need this. (Now I don't remember what the motivation was, but I think it had to do with coordinating different elements of a plot.) In any case, the decorator is actually very specific to rasterization, so maybe call it @with_rasterization or @allow_rasterization. I am very anxious to see rasterization support in place; let's just be sure we have a good API and mechanism. The patch looks reasonable to me, but I have no experience in writing decorators, and have not had time to really think about the rasterization API problem. I like Eric's suggestion to rename the decorator if its only purpose is to handle rasterizing. A generic draw hook solution would be fun to develop, but I don't have time for that learning curve at the moment. So a raster-specific decorator is good by me; I like @allow_rasterization. It's correct that I'd need someone to commit the patch for me. In my view, renaming the decorator is a simple search-replace that can be handled by the committer, but I'm happy to help with any changes we agree on. One I thing I want to add your patch is to warn users when they set rasterized attribute of the artists whose draw method is not decorated. I'll think about it later but feel free to propose any. I have no experience with decorator detection. Presumably you can so some sort of inspection of self.draw in Artist.set_rasterized. Thanks, Eric B Thanks, -JJ -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] crazy ideas for MPL
On Wed, Jul 1, 2009 at 9:51 PM, Andrew Strawstraw...@astraw.com wrote: Gael Varoquaux wrote: On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote: Anyone interested? And if so, feel free to suggest topics or weigh in on some I listed. Actually, I have something I would like to discuss, but never really could pull myself together to do it. I don't have time right now, but I am still going to jot down the ideas. The axes and figure paradigm inherited from matlab works well for simple things, but when I want to more complex layouts, I actually end up struggling with calls to axes with numerical parameters to adjust. In addition, if I have a function that creates a plot with multiple axes, like the figure on: http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html I may want to reuse that function to create more complex figures, stacking several of these views, with possibly other plots. It seems to me having a level of granularity between the figure, and the axes would help me a lot achieving these goals. I haven't had time to hash out an API, or even solid concepts. For people who know LaTeX well, let me draw an analogy: the figure is the page, the axis is the character, what we are lacking in a 'minipage'. I would like a container that can be stacked into a figure, and that can either hold axes, or similar containers. That way, I could specify subplot, or axis relative to this container, rather than relative to the whole figure, and it makes it really easy for me to insert figures in larger figures. One possible API would be 'subfigure', which would have a signature similar to 'axes', but of course things would need to be thought a bit more in detail: do we want clf to erase the figure and not the subfigure? I believe so. Do we want subplot to divide the subfigure, rather than the figure? I believe so too. How do we go back to full figure without erasing the subfigures it contains? I think subfigure(None) might work. How do I select a subfigure I already created? Maybe by passing it a subfigure instance, like the way axes work. Also, Chaco has the notion of containers, in which you can stack plots or other containers. They have an additional feature which is that they enable you to stack plot (these would be axes, in matplotlib terms) and do an automatic layout of the plots. Very handy to have an extensible canvas to display information on. Some sparse documentation: http://code.enthought.com/projects/chaco/docs/html/api/containers.html I have been trying to find time to think about this for more than a year, and haven't. This is why I am sending unfinished thoughts. I do believe more thinking has to be done, and the subfigure proposition may not hold at all. Also, I fear I do not have time to implement this. I also have some not very fleshed out thoughts: my main feeling about MPL is that there's just too much layout happening to keep using the non-systematic delegation/notification system currently in place while allowing the devs to maintain their sanity and day jobs. I don't mean to disparage MPL -- it is quite a fantastic piece of code -- but there is a lack of abstraction of layout hierarchies and layout dependencies that makes development difficult. Therefore, I'd suggest that before adding on too many more nice features, we revisit the core layout and delegation system -- in the end it will make everything much easier. So, perhaps a useful thing would be for as many MPL devs as possible to sit together and discuss how we could do this. My thought right now would be to investigate the use of traits to codify the layout abstractions. Any effort like this will also obviously benefit from having an extensive test suite. I think all that's needed to get the tests at http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone checks in new images made with the current MPL. I'd like to do this, but I'm really short on time at the moment. So, please, someone -- beat me to it -- it won't be hard! Those are my 2 cents. Hope to see you all at SciPy 2009! -Andrew While we're dreaming big re-architecting dreams, I'll throw out an idea related to Gael's suggestion: artist containers at the sub-axis level. This would be a drawable / hideable container for an arbitrary grouping of Artists that could be directly added to one (or more) Axes. For those familiar with IDL, the IDLgrContainer in their object graphics system is what I have in mind. I also concur with Andrew's assessment that interactive and layout event handling is holding back some extra fun in interactive apps. I have mixed feelings about using Traits; in my experience with writing (only one) app, I felt like I had to subsume everything, my data modeling included, under the Traits paradigm, such that I was no longer writing Python but Traits. I found it very hard to include other data objects created by other libraries without
[matplotlib-devel] building from SVN on Mac OS X 10.5
Just got a new Mac, and went with Python 2.6 from python.org on OS X 10.5. My experience building Matplotlib was less than smooth, and I thought I'd pass along what eventually wound up working. To summarize: 1. Rolling your own libpng and freetype in /usr/local appears to lead to a lot of architecture mismatch heartache, even though the libs compile fine out of the box 2. The official recommendation at http://matplotlib.sourceforge.net/users/installing.html#build-osx doesn't work because OS X doesn't ship with wget and because the download URLs for zlib, libpng, and freetype are broken in matplotlib/release/osx 3. I had success by following the instructions at http://ipython.scipy.org/moin/Py4Science/InstallationOSX, but I had to change the build command to: env ARCHFLAGS='-arch i386' CFLAGS=-Os -arch i386 LDFLAGS=-Os -arch i386 python setup.py build The ARCHFLAGS suggestion was taken from http://www.nabble.com/Building-matplotlib-on-os-x-to24942879.html, which had a few other scary ideas that I didn't have the heart to try. This built (I think) an intel-only i386 (32 bit) Matplotlib, which is fine for my local use. If I can help debug a better build process, let me know; I can probably help test for the next week on this new machine. -Eric -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] building on OSX
Hi Ariel, Thanks for the suggestion. Combining John's new makefile with the changes to the Python.framework Makefile yielded: distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.4 but 10.5 during configure. As a general philosophy, I'm a bit hesitant to go about changing stuff that's part of the Python framework directory structure. I'd be worried about ripple effects when debugging other builds in a couple months when I forget that I've modified it. As I noted the other day, from a clean SVN checkout on 10.5/py 2.6, this one-liner works: env PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig ARCHFLAGS='-arch i386' CFLAGS=-Os -arch i386 LDFLAGS=-Os -arch i386 -L/usr/X11R6/lib python setup.py install This avoids libgcc from gfortran in /usr/local/lib and doesn't require building anything extra. I suppose it's not portable to 2.4 and/or 10.4, though. I'm willing to try some more builds if it would help, though it appears I just keep uncovering problems :( -Eric On Mon, Aug 24, 2009 at 5:06 PM, Ariel Rokemaro...@berkeley.edu wrote: Hi Eric, you could try making changes to your Python Makefile, as described here (in item 1): http://matplotlib.sourceforge.net/faq/installing_faq.html#building-and-installing-from-source-on-osx-with-epd Even if you are not installing on the basis of the EPD, it might still solve your issue. Cheers, Ariel On Mon, Aug 24, 2009 at 1:47 PM, Eric Bruningeric.brun...@gmail.com wrote: For some reason, it's still picking up the gfortran-installed gcc in /usr/local/lib, which is also listed in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib (along with everything else in /usr/local/lib). I also still see -L /usr/local/lib even though the darwin setupext.py key no longer includes it. I'm flummoxed. Apparently I should back up and try without gfortran first, but that's a typical way to meet requirements for scipy that I'd like to have around. -Eric g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -arch i386 -arch ppc -L/usr/local/matplotlib/lib -syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -I/usr/local/matplotlib/include -I/usr/local/matplotlib/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk build/temp.macosx-10.4-fat-2.6/src/ft2font.o build/temp.macosx-10.4-fat-2.6/src/mplutils.o build/temp.macosx-10.4-fat-2.6/CXX/cxx_extensions.o build/temp.macosx-10.4-fat-2.6/CXX/cxxsupport.o build/temp.macosx-10.4-fat-2.6/CXX/IndirectPythonInterface.o build/temp.macosx-10.4-fat-2.6/CXX/cxxextensions.o -L/usr/local/lib -lfreetype -lz -lstdc++ -lm -o build/lib.macosx-10.4-fat-2.6/matplotlib/ft2font.so ld warning: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.4.dylib, missing required architecture ppc in file ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib, missing required architecture ppc in file for architecture ppc collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/RP/RPE-UjrSHZ4SQq6AJQBxqk+++TI/-Tmp-//ccAqigF2.out (No such file or directory) error: command 'g++' failed with exit status 1 make: *** [mpl_build] Error 1 On Sun, Aug 23, 2009 at 1:33 AM, John Hunterjdh2...@gmail.com wrote: The problem of building on OSX, in particular the setupext basedir search path including /sw, /usr and /usr/local, appears so fraught with peril -- we don't know what kinds of libs built with what kinds of flags that we will find -- that I removed all the dirs from the basedir for darwin. Instead, I am hoping that the new makefile.osx Makefile I have added, which will fetch and build the required libs and install them into the PREFIX of your choice, will prove more supportable. I have tested this on a couple of platforms and it worked well, but there are other combinations that I do not have access to so please let me know if this is not viable. I am currently building with PREFIX=/Users/jdhunter/dev make -f makefile.osx fetch deps mpl_install Builds with enthought python make still be broken due to the issues in the FAQ: http://matplotlib.sourceforge.net/faq/installing_faq.html#building-and-installing-from-source-on-osx-with-epd Please kick the tires and give some feedback JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
[matplotlib-devel] Basemap.shiftgrid without cyclic point
I'm using basemap to plot a dataset* that has longitude values like so: lon = [0, 2, 4, ..., 356, 358] I'd like to use Basemap.shiftgrid to transform the longitudes and data to the -180, 180 interval, but I get 'ValueError, cyclic point not included' since 360 isn't among the longitudes. Attached is a version of shiftgrid that attempts to handle the non-cyclic case. There are pseudo-unit-tests that demonstrate the cyclic and non-cyclic case for a 180 degree shift. Thanks, Eric *SST anomalies from http://nomads.ncdc.noaa.gov/thredds/dodsC/ersstv3Agg shiftgrid.py Description: Binary data -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Memory leak with rasterized pcolormesh and savefig
Hi all, I've come across a memory leak when saving multiple figures in a row. The figure contains a single pcolormesh artist, which I need to rasterize in my application. However, turning on rasterization causes a memory leak.The attached script reproduces the problem; swap out the commented section at the bottom to eliminate memory growth for each new figure. I'm not sure what the cause is, though to toss one idea out, might it have to do with a references that aren't cleaned up from the rasterizing part of the mixed-mode renderer? Tested on Mac OS X and, thanks to Patrick Marsh, on Windows. Thanks, Eric from matplotlib.backends.backend_agg import FigureCanvasAgg from matplotlib.figure import Figure from matplotlib.colorbar import ColorbarBase # from matplotlib.cm import get_cmap import numpy as np import gc def test_rasterized_artist(rasterize_mesh=True): Save an image as a png file pdfpath = 'test_mplsave.pdf' xedge = np.arange(11)-5 yedge = np.arange(11)-5 density = np.arange(100).reshape((10,10)) fig = Figure(figsize=(8,8)) canvas = FigureCanvasAgg(fig) fig.set_canvas(canvas) ax = fig.add_subplot(1,1,1) density_plot = ax.pcolormesh(xedge,yedge,density) density_plot.set_rasterized(rasterize_mesh) fig.savefig(pdfpath, dpi=150) # The below is not necessary to prevent a leak, but it does make # memory usage more compact gc.collect() # This leaks for i in range(100): test_rasterized_artist(rasterize_mesh=True) # # This doesn't # for i in range(100): # test_rasterized_artist(False) -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Thoughts about callbacks
On Mon, Oct 25, 2010 at 9:40 AM, Michael Droettboom md...@stsci.edu wrote: On 10/23/2010 06:05 PM, David Carmean wrote: As I blurted on -users, I'm thinking lately about callbacks in the non-GUI portions of the libraries--mostly Artist and subclasses. I'm curious if anybody else has been thinking about them? Ideally, I'd like to see the following: All of the Artist subclasses, and anything else that might belong to a Figure, would be updated to use/add cbook.CallbackRegistry callbacks (weakref = good thing). In addition to emulating/replacing the simplistic 'pchanged' callback with a signal of that same name, there would be a signal named after each setter method, and said methods fire off their eponymous signal after they modify the property. There should be some way to rate-limit or temporarily block individual signals or callback connections. The various constructors, etc, would be modified to subscribe to the 'pchanged' signal of all children, such that even if a particular object in the middle of a figure heirarchy does nothing with the signal, a sort of a global 'pchanged' signal propagates up to the top object (FigureManager, Canvas, Figure, something). My current Use Case for these features is in experimenting with different Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired of calling canvas.draw() all the time :) But also, I'm working on a GUI to do the same (traits UI), and want to tie both layers of the model together with callbacks to speed up the experimenting. I've spent a few hours this weekend doing some meta-monkey-patching-- using __getattribute__ to decorate the setters on-the-fly to invoke callbacks.process(*args) after the changes. I have a few more quick hacks to try before I'm ready to decide on a production-ready strategy. It's great to see someone working on this. Similar ideas have been thrown around since at least as long as I joined the party in 2007 (search the e-mail archives for Traits). I like your approach because it should allow for a tighter integration of Traits, while at the same time not adding Traits as a dependency. It just might be the elusive middle ground that prevented us from really going forward way back when. Mike +1 on Mike's middle-ground idea. In case you haven't seen it, decorators are presently used to allow Aritist.draw to make a raster mode switch for a MixedModeRenderer. It's really a generic per-artist before/after draw signal implemented for that single purpose. This could potentially be refactored if there's a new signaling system in place. -Eric -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] blit support in webagg / nbagg backends?
I see that supports_blit=False in FigureCanvasWebAggCore. Is there a technical limitation that prevents this, or is it a matter of someone finding time to do the implementation? Absence of blit support doesn't seem to crash code that uses it (in my case, a lasso tool), but I also see no output to the screen. Thanks, Eric -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
