Re: [matplotlib-devel] Thoughts about callbacks
On Sat, Oct 23, 2010 at 5: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. > > So my question today is: is anyone interested in discussing these > ideas and how to implement them? I'm interested. I was just noticing a need for the signals to simplify some interactive stuff I was doing. I'm not wild about using the current incarnation of the CallbackRegistry, since it doesn't allow you to add signals after you create the object. Also, there are only global signals, you can't connect to a specific object (unless you were planning on each object having its own registry?). When I was considering this yesterday, I was looking at these: http://code.activestate.com/recipes/87056/ http://pydispatcher.sourceforge.net/ Also, had you given any thought to using decorators to note methods that emit a certain signal, or to connect one method to a given signal? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Nokia and AT&T 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
Re: [matplotlib-devel] Blitting for animations
[Putting this back on list after I mistakenly took it off.] On Fri, Oct 22, 2010 at 11:45 PM, Michiel de Hoon wrote: > Hi Ryan, > > Thanks for your reply. > > --- On Mon, 10/18/10, Ryan May wrote: >> In the course of adding the animations, I also >> added a "close_event" to the other backends, so that the >> timers would stop on figure close and the users wouldn't >> get weird messages. Did you happen to add this? > > I added the close_event to the Mac OS X backend today. > >> I'm not sure you can move this to figure.draw(renderer), >> since that's going to draw *everything*. > > One solution is to add an .animation attribute to the Figure class, which is > None by default (for non-animated drawing). > > Roughly, the code should then look as follows: > > In the Animation class, the _step method sets Figure.animation and lets the > canvas know that it should redraw itself: > > def _step(self, *args): > try: > framedata = self.frame_seq.next() > self.figure.animation = self, framedata > self.figure.canvas.draw_idle() > return True > except StopIteration: > return False > > Note that no actual drawing is done here. > > In the Figure class, the draw method should then become: > > def draw(self, renderer): > if self.animation: > animation, framedata = self.animation > animation._draw_next_frame(framedata, animation._blit) > return > # otherwise, draw as usual. > > Then all actual drawing is done from inside Figure.draw, which is what the > Mac OS X backend needs. > > How does this look? If this looks OK, I can try to work out the details and > send you the modified code so you can check it out. I'm not completely wild about it, because it just feels wrong to put something specific to animation inside figure. The problem we're trying to solve here is biltting, so is there some way we can improve how blitting is handled? This would also be a time where we could (possibly) simplify/improve the blitting API. Do any of the current uses of blitting work with the MacOSX backend? If those *do* work, then I'm doing something wrong and need to rework animations. If not, then we need to find a way to make it so blitting can work in general. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Nokia and AT&T 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
Re: [matplotlib-devel] Thoughts about callbacks
On Sun, Oct 24, 2010 at 10:35:03AM -0500, Ryan May wrote: > On Sat, Oct 23, 2010 at 5:05 PM, David Carmean wrote: [snip] > > 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. > > > > So my question today is: is anyone interested in discussing these > > ideas and how to implement them? > > I'm interested. I was just noticing a need for the signals to simplify > some interactive stuff I was doing. I'm not wild about using the > current incarnation of the CallbackRegistry, since it doesn't allow > you to add signals after you create the object. Also, there are only > global signals, you can't connect to a specific object (unless you > were planning on each object having its own registry?). When I was > considering this yesterday, I was looking at these: > > http://code.activestate.com/recipes/87056/ > http://pydispatcher.sourceforge.net/ > > Also, had you given any thought to using decorators to note methods > that emit a certain signal, or to connect one method to a given > signal? I've gone through the same thought process. I do plan to add a CallbackRegistry.add_signals method; I am giving each instance it's own registry instance (axes.Axes already does this); and I am using decorators. -- Nokia and AT&T 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
Re: [matplotlib-devel] sub-sub-plots, sub-sub-sub-plots, etc.
On Fri, Oct 22, 2010 at 5:09 PM, Kynn Jones wrote: > I need to generate a fairly complex chart, for which I need the ability to > specify not only subplots, but also sub-subplots, and even > sub-sub-sub-plots. (Our group has found such charts useful in the past, but > they were generated using horrific MATLAB code.) > > I'll try to describe what I want to do in a bit more detail (it's messy). > > First imagine a simple plot (just a simple X-Y line graph connecting 3-4 > datapoints). I'll call this a level-0 plot. Now, join ~10 of these level-0 > plots side-by-side (with no space between the plots). This new aggregate is > a level-1 plot. Next stack ~10 level-1 plots vertically, again, with no > space between them. The resulting aggregate is a level-2 plot. Finally > arrange ~10 of these level-2 plots side-by-side, with some spacing between > them. The desired final product is this level-3 plot. > > Without knowing much about the internals of matplotlib, it seems to me that > the best way to do this would be to define a container class that can have > itself as one of the contained elements. In this way, a containment > hierarchy of arbitrary depth could be defined. But it is my understanding > that there is no immediate way to do this in matplotlib now, so I'd have to > implement it myself. > > I could use some guidance to the source code. > > What I need to clarify is the following. First consider some simple plot > A: it has axes, data points, tick marks, labels, etc., and for all these > elements there are associated absolute x-y coordinates on the canvas. If > now we make this plot A one of the subplots in a collection of, say, 12 > subplots, arranged as 3 rows of 4 subplots each, all the x-y coordinates > associated with the original plot A will have to be translated and scaled, > so that the subplot lands in the right place on the canvas, and has the > appropriate size. This process of translation and scaling is what I want to > pinpoint: What exactly is the connection between running the add_subplot > method and the translation+scaling that it entails? > > What would be a good entry point for me to answer the questions above by > reading the source code? > > TIA! > > ~kj > > Looks like you are talking about an arbitrarily deep hierarchical subplotting feature. I am not exactly sure how feasible/unfeasible this is, but a good place to start might be to take a look at the axes_grid toolkit that does a lot of very advanced axes organizational tricks. http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html I hope this proves useful, or at least inspires you for ideas on how to accomplish what you are looking for cleanly. And, as always, patches are always welcome! Ben Root -- Nokia and AT&T 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
Re: [matplotlib-devel] Blitting for animations
--- On Sun, 10/24/10, Ryan May wrote: > > One solution is to add an .animation attribute to the > > Figure class, which is None by default (for non-animated > > drawing). > I'm not completely wild about it, because it just feels > wrong to put something specific to animation inside figure. OK I see your point. > The problem we're trying to solve here is biltting, so is > there some way we can improve how blitting is handled? For a general API for blitting (something that is not restricted to animations), we need two functions: one that tells matplotlib that we want to blit something, and one that does the actual blitting. Right now we only have the latter. Let me point out also that there is nothing peculiar about blitting in Quartz. It's just that in Quartz all drawing operations should be performed from inside the event loop. For comparison, this is roughly what happens if you draw a line: plot(x,y) # tells matplotlib that we want to draw a line # this triggers a call to draw_if_interactive() # this marks the canvas as invalid # the event loop then calls a callback function to redraw the canvas # the callback function calls figure.draw(renderer) # which calls renderer.draw_path # which does the actual drawing For a general blitting API, we need the equivalent of the plot function; something that informs matplotlib that we want to blit but doesn't do the actual blitting. The actual blitting should then be done from inside figure.draw. If you just want to implement blitting for animations, one option is to add a draw() method to TimedAnimation, and to set fig.draw = self.draw in the __init__.py of TimedAnimation. Then when a figure needs to be redrawn, TimedAnimation.draw will be called from inside the event loop. Such a TimedAnimation.draw function should then be roughly the same as the current _draw_next_frame function. Best, --Michiel. -- Nokia and AT&T 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
Re: [matplotlib-devel] sub-sub-plots, sub-sub-sub-plots, etc.
On Sat, Oct 23, 2010 at 7:09 AM, Kynn Jones wrote: > Without knowing much about the internals of matplotlib, it seems to me that > the best way to do this would be to define a container class that can have > itself as one of the contained elements. In this way, a containment > hierarchy of arbitrary depth could be defined. But it is my understanding > that there is no immediate way to do this in matplotlib now, so I'd have to > implement it myself. Matplotlib has a simple hierachy of Figure-Axes-Artists (this is not 100% correct description as a matter of fact, see http://matplotlib.sourceforge.net/users/artists.html for more details). All Axes instances have associated positions within a figure instance. If you want to have a hierarchy of multiple axes, what you can do basically is to make those positions in hierarchical manner. This can be very trivial depending on what exactly you want (e.g., how you want the axes sizes (and the gaps inbetween) specified). However, there are a few ways to ease this process. http://github.com/astraw/mplsizer mpl v1.0 has gridspec. http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-using-subplotspec For example, you may do something like import matplotlib.gridspec as gridspec fig = gcf() gs0 = gridspec.GridSpec(2, 2) ax = fig.add_subplot(gs0[0, 0]) gs00 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs0[1]) ax2 = fig.add_subplot(gs00[0]) gs000 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs00[1]) ax3 = fig.add_subplot(gs000[0]) Or, you can use axes_grid toolkit as mentioned above. Regards, -JJ -- Nokia and AT&T 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
