Ok, I have some questions about what the protocol for patch submission should be, in terms of 'completeness' of the patch. I have a patch for the quiver function that is half done... it has converted the arrows from patches to linecollections, and it will accept arbitrary X and Y coordinates for the arrow positions, as suggested by Rob. Unfortunetly, none of the color functionality is working. Partly this is because the color functionality of LineCollection is different from PolyCollection (which quiver originally used) and partly because I don't understand how matplotlib sets colors at all. Should I submit this half finished patch so that others can have a chance to improve the color function? Or should I not submit until I figure out how color works and fix the thing? Furthermore, can LineCollection actually do all the things that quiver's old color commands demand of it? I don't see a place to set a colormap for a LineCollection, but as I said, I don't understand it very well. Jordan
>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes: Jordan> Ok, I have some questions about what the protocol for Jordan> patch submission should be, in terms of 'completeness' of Jordan> the patch. Jordan> I have a patch for the quiver function that is half Jordan> done... it has converted the arrows from patches to Jordan> linecollections, and it will accept arbitrary X and Y Jordan> coordinates for the arrow positions, as suggested by Rob. Jordan> Unfortunetly, none of the color functionality is working. Jordan> Partly this is because the color functionality of Jordan> LineCollection is different from PolyCollection (which Jordan> quiver originally used) and partly because I don't Jordan> understand how matplotlib sets colors at all. Should I Jordan> submit this half finished patch so that others can have a Jordan> chance to improve the color function? Or should I not Jordan> submit until I figure out how color works and fix the Jordan> thing? I don't recommend submitting patches that don't work. Rather, post code samples here with questions in the areas you need help. Jordan> Furthermore, can LineCollection actually do all the things Jordan> that quiver's old color commands demand of it? I don't Jordan> see a place to set a colormap for a LineCollection, but as Jordan> I said, I don't understand it very well. You can create a line collection that is color mappable by deriving from LineCollection and ScalarMappable. It will take a little more work to fully integrate it into the colormappable framework, eg so colorbars and interactive changing of colormaps works as expected, but this may be enough to speed you along This is a good example of how you can extend and specialize the existing classes if they don't behave like you want them to. from matplotlib.colors import normalize from matplotlib.cm import ScalarMappable, jet from matplotlib.collections import LineCollection from pylab import figure, show, nx class LineCollectionSM(LineCollection, ScalarMappable): def __init__(self, segments, x, norm, cmap, # and the other args for LineCollection ): LineCollection.__init__(self, segments) ScalarMappable.__init__(self, norm, cmap) self.set_array(x) def draw(self, renderer): self._colors = self.to_rgba(self.get_array()) LineCollection.draw(self, renderer) def random_segment(): x1, y1, x2, y2 = nx.mlab.rand(4) return (x1, y1), (x2, y2) segments = [random_segment() for i in range(50)] x = nx.mlab.rand(50) col = LineCollectionSM(segments, x, normalize(), jet) fig = figure() ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False) ax.add_collection(col) show()
> > You can create a line collection that is color mappable by deriving > from LineCollection and ScalarMappable. It will take a little more > work to fully integrate it into the colormappable framework, eg so > colorbars and interactive changing of colormaps works as expected, but > this may be enough to speed you along John, Is there any reason not to simply make LineCollection inherit from ScalarMappable the same way that PatchCollection does? I don't see any real disadvantage or backwards incompatibility, and I think it would be useful and add consistency. I can do it today, barring unforseen problems with related changes I am making. Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Is there any reason not to simply make LineCollection Eric> inherit from ScalarMappable the same way that Eric> PatchCollection does? I don't see any real disadvantage or Eric> backwards incompatibility, and I think it would be useful Eric> and add consistency. I can do it today, barring unforseen Eric> problems with related changes I am making. I think this looks like a good idea too. JDH
Jordan, Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..." My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.) Eric ----- Original Message ----- From: Jordan Dawe <jdawe@u.washington.edu> Date: Monday, May 29, 2006 7:18 pm Subject: [matplotlib-devel] Quiver To: matplotlib development list <mat...@li...> > Ok, I have some questions about what the protocol for patch > submission > should be, in terms of 'completeness' of the patch. > > I have a patch for the quiver function that is half done... it has > converted the arrows from patches to linecollections, and it will > accept > arbitrary X and Y coordinates for the arrow positions, as suggested > by > Rob. Unfortunetly, none of the color functionality is working. > Partly > this is because the color functionality of LineCollection is > different > from PolyCollection (which quiver originally used) and partly > because I > don't understand how matplotlib sets colors at all. Should I > submit > this half finished patch so that others can have a chance to > improve the > color function? Or should I not submit until I figure out how > color > works and fix the thing? > > Furthermore, can LineCollection actually do all the things that > quiver's > old color commands demand of it? I don't see a place to set a > colormap > for a LineCollection, but as I said, I don't understand it very well. > > Jordan > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and > Risk!Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as- > us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Eric Firing wrote: > Jordan, > > Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..." > > My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.) > > Eric > No, I am not sure we want to use LineCollection. I am using it because it is harder to see the distortions introduced by data coordinates when lines are used instead of polygons. I don't understand the transforms and I feel I have zero chance of getting a good looking plot in a reasonable length of time working with polygons. So I've been going the LineCollection way for two reasons: one, Gary's post with his line arrow seemed to indicate he was working in that direction as well (although it appears I was hasty to assume that, judging by his follow-up post), and two, because I figured I could get something going quickly and then build on it. So really, this isn't a transform issue anymore, because I've abandoned that idea as beyond my abilities. If you all feel that turning quiver into line objects isn't a good idea, then there's not really much work I can do on it; the polygons work as well as they are going to as-is. Also, a question: why use collection objects? The implimentation doesn't strike me as being much faster rendering wise, but maybe I'm wrong. Is it just so all the objects can be manipulated all at once by changing the state of the collection? Also, is there any particular reason the collections only accept verts or segments, instead of being able to just send it a patch or line object and have the collection object extract the relevant data? Jordan
>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes: Jordan> Also, a question: why use collection objects? The Jordan> implimentation doesn't strike me as being much faster Jordan> rendering wise, but maybe I'm wrong. Is it just so all Jordan> the objects can be manipulated all at once by changing the Jordan> state of the collection? collections aren't as fast as they can be, mainly because they use sequences of python objects rather than numeric arrays, so all the object coercion still has to be done. Their primary efficiency is the avoidance of repeated object creation and their attendant function calls and setting the graphics contect. Eg, if you create 10000 Line2D objects, you will pay for 10000 object creations, 10000 separate transformations, 10000 calls to the renderer draw function, and 10000 settings of the gc state. With a collection, you have a lot less overhead, but they are still too slow for some purposes. Jordan> Also, is there any particular Jordan> reason the collections only accept verts or segments, Jordan> instead of being able to just send it a patch or line Jordan> object and have the collection object extract the relevant Jordan> data? Currently the collections are designed to be flexible (eg, each polygon can have separate color and width properties) and reasonably fast. They are not particularly easy to use, so some helper functionality would be useful. JDH
> Jordan> Also, a question: why use collection objects? The > Jordan> implimentation doesn't strike me as being much faster > Jordan> rendering wise, but maybe I'm wrong. Is it just so all > Jordan> the objects can be manipulated all at once by changing the > Jordan> state of the collection? > > collections aren't as fast as they can be, mainly because they use > sequences of python objects rather than numeric arrays, so all the > object coercion still has to be done. Their primary efficiency is the > avoidance of repeated object creation and their attendant function > calls and setting the graphics contect. > > Eg, if you create 10000 Line2D objects, you will pay for 10000 object > creations, 10000 separate transformations, 10000 calls to the renderer > draw function, and 10000 settings of the gc state. > Cool, that makes sense. Another question: what plot types generate 10000 Line2D objects? I can see quiver doing something like that if one plots an 100x100 grid, but it seems to me the resulting arrows would be totally unreadable. I hope I'm not coming across as snotty here. I really love matplotlib, it's all I use nowadays, and quite an amazing piece of code. I want to find someplace where I can start adding functionality, but the backend is really confusing me. I guess I'm trying to figure out what bits of the code are design decisions and what bits are there because they worked, but aren't necessarily the best solution. > Jordan> Also, is there any particular > Jordan> reason the collections only accept verts or segments, > Jordan> instead of being able to just send it a patch or line > Jordan> object and have the collection object extract the relevant > Jordan> data? > > Currently the collections are designed to be flexible (eg, each polygon can > have separate color and width properties) and reasonably fast. They > are not particularly easy to use, so some helper functionality would > be useful. > Cool, so I take this to mean it would be helpful to add some code to the __init__() funcs of the collection objects so they can accept objects as well as vertex data? Cause I think I could do that. So, are the basic drawing primitives in matplotlib Line2D, LineCollection, Patch, and PolyCollection, with QuadMesh a special case so that pcolor renders fast? Jordan
>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes: Jordan> Cool, that makes sense. Another question: what plot types Jordan> generate 10000 Line2D objects? I can see quiver doing Jordan> something like that if one plots an 100x100 grid, but it Jordan> seems to me the resulting arrows would be totally Jordan> unreadable. some contours may generate this many line objects. scatters and pcolors can generate tens of thousands of polygons or more... Never underestimate the power of the user to throw more stuff into a plot than previously thought impossible. Jordan> Cool, so I take this to mean it would be helpful to add Jordan> some code to the __init__() funcs of the collection Jordan> objects so they can accept objects as well as vertex data? Jordan> Cause I think I could do that. My weak preference is to have higher level functions that create the collection objects (think Axes.scatter, Axes.pcolor or many of the functions in the finance module) rather than overloading the constructor, which might get confusing. A Collection is at the level of Line2D -- most users don't create them directly, and helper functions should make them easy to use. Jordan> So, are the basic drawing primitives in matplotlib Line2D, Jordan> LineCollection, Patch, and PolyCollection, with QuadMesh a Jordan> special case so that pcolor renders fast? The base types are Text, Line2D, Patch, Image and Collection. Some of these are specialized, eg TextWithDash inherits from Text, Polygon and Rectangle inherit from Patch, LineCollection inherits from Collection and so on. There are several types of Images. There is an artist hierarchy diagram in the PDF user's guide which is fairly comprehensive but not entirely up-to-date, eg QuadMesh is not there. Regarding the design question. I think there is near uniform consensus that the transforms are kludgy and hard to work with, but as Andrew has pointed out, it would be a lot of work to replace them with something more intuitive since they pervade the code; "open heart surgery on matplotlib", I think he called it. It would have been a good summer-of-code project. I think it is a reasonably hard problem -- how to support affines plus general non-linear transformations and have your transformations efficiently updated in the presence of window resizes and the like. Certainly not a very hard problem -- lots of people have solved it -- but nontrivial. Typically one ends up special casing the common transformations, so polar plots are supported with custom axes. One could make a generic axes object that drew good tick lines and labels in the presence of arbitrary nonlinear transformations on non-separable axes, but it would take some smarts. One of the things that makes transformations hard to do well is that beyond the pure math of affines and functions on those affines, which is pretty easy, you have to make the results play nicely in the presence of axes graphs that have tick labels on them in nice places and user's who want to pan and zoom. What should zoom-to-rect do on a polar axes? I regard the collections as a bit kludgy too -- I had a few specific use cases I was targeting, basically a few plots types where lots of objects were being creates: scatters, pcolors, financial candlestick plots, and tried to find some common denominators. Collections were the first attempt at solving this problem, and I think I traded too much flexibility for a somewhat non-intuitive interface and subpar performance. There is yet room to either refactor the existing collections or design new ones to solve specific problems better (think QuadMesh). Whatever their current short-comings, I still think back fondly to the bad-old-days, when the pcolor_demo advised you to "go get a cup of coffee" while you waited for it to render. And it really took that long. The Axis code needs some improvement, because the notion of each Axes having a single x-axis and y-axis is fairly limiting, and the ticking is too slow. Separate objects for each tick line and label slow things down a lot. The Axes code does too much -- handling almost all of the object creation and the objects these methods return are too primitive (eg plot, scatter and pcolor are axes methods that return graphics primitives like Line2D). There is some consensus that we should have high level plot objects (FunctionItem, ScatterItem, XYPlotItem) which are created separately from an Axes and contain their primitive graphics objects. This is closer to the gnuplot model. Many of the other objects seem to be holding up fairly well and handle common and unusual cases fairly elegantly -- the FigureCanvas, Figure, Line2D, Patch, Text and matplotlib Events seem to work pretty well. Hope this helps, JDH
John Hunter wrote: > Hope this helps, > JDH > Sweet, that helps a lot. Thank you very much. Jordan
Jordan, Gary, I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be preserved or not, depending on the units one chooses. Below a threshold, the whole arrow is scaled down as its length is reduced; above that threshold, only the length changes. I am subclassing PolyCollection, so there is full flexibility in rendering with or without an edge. I expect I will be ready to commit something within a week. Eric
This is good news Eric and sounds like the desired behaviour. Thanks for letting me know. I was intending to try to work it out this weekend but have spent my time instead learning to build numpy/scipy/matplotlib from source - a worthwhile exercise. I don't think JDH/Charlie should wait for new quiver plots before doing another release. On the scaled down arrows, do you see strange artifacts when viewing at certain magnifications? JDH thought this might be due to subpixel rendering problems, although I wasn't sure that was the reason. I look forward to seeing how the transform stuff works. I found it all a bit unfathomable. thanks, Gary Eric Firing wrote: > Jordan, Gary, > > I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be preserved or not, depending on the units one chooses. Below a threshold, the whole arrow is scaled down as its length is reduced; above that threshold, only the length changes. I am subclassing PolyCollection, so there is full flexibility in rendering with or without an edge. > > I expect I will be ready to commit something within a week. > > Eric
Robert Hetland wrote:
>
> Let me know if you would like to do a quick alpha test before you
> commit. I'll help to put it through the paces..
>
> -Rob.
Rob,
Thanks. Attached are a diff against svn and a test script to get you
started. If you apply the diff as a patch, you should be able to call
quiver2 from the pylab interface. Docstrings are provided. I made no
attempt to copy the kwarg part of the API from the old quiver; this one
is just too different. Most of the arg part of the API is the same,
except that the optional third or fifth argument is a mappable array
instead of a scale; I made the scale a kwarg, and it operates completely
differently from the one in the old quiver--but for good reason, I think.
The key idea for the scale is that the "units" kwarg establishes a unit
of measure ("arrow unit") for the arrows, and the scale gives the U,V
data units per arrow unit. For example, if units="inches" and you have
a 1 m/s velocity vector, then setting scale=2 will mean 2 m/s per inch,
and the vector will be half an inch (assuming the figure dpi value is
correct), regardless of how you change the window size or zoom. If
units="x", and your x-axis goes from 0 to 50 km, then you might set
scale=1/5.0 so that 1 m/s corresponds to 5 km along the x-axis; if you
zoom in, the vector will grow. If units="width" (present default, though
maybe not a good one), then the unit is the width of the plot, so you
might make scale=50, so that 1 m/s makes an arrow 1/50th the width of
the plot. Change the window width, and the arrow length changes along
with it. Zoom, and it does not change, however. In all cases, the
arrow direction remains constant, regardless of window or view limit
manipulations. (This is all because of John's transform magic--it is a
little hard to understand at first, but it certainly provides wonderful
functionality.)
There is a simple auto-scaling algorithm, so one does not have to
specify the scale kwarg initially.
Once quiver.py is in place, I will add related functionality such as
ellipses, so you can plot mean velocities and standard error ellipses,
for example.
One thing I have not looked into yet is what it will take to do all this
correctly with polar axes and with basemap, which I will need.
Eric
Hi Eric, Having entered the build-from-source world with the latest ubuntu, I applied your patch and tried it out with the example code I sent you using a call similar to quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) This works very nicely for my purposes - perfectly in fact. Many thanks for your work on this. The only thing I think might be nice to add is some sort of minsize parameter so that you could get a pixel or something marking the existence of a data value for a grid point or a tiny arrowhead, sort of like the current svn quiver behaves, but size settable. I tried adding linewidths=(1,) to see if this would work. It sort of works, but looks pretty ugly and I think confirms my suspicion that the problems I had seen in my attempts were due to line stroking. Thanks and good work! Gary
Gary, Thanks for the prompt test and report. I agree that the ability to put a dot at locations where arrows are below a threshold would be good. I will add it. I think it should be similar to a circle marker that scales with the arrow width, and has a diameter that is a fraction of that width. I also observed the stroking problem with small arrows and finite linewidth. I haven't checked into it, but I am wondering whether the problem is in the specification of the line join type. Eric Gary Ruben wrote: > Hi Eric, > > Having entered the build-from-source world with the latest ubuntu, I > applied your patch and tried it out with the example code I sent you > using a call similar to > > quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) > > > This works very nicely for my purposes - perfectly in fact. > Many thanks for your work on this. > The only thing I think might be nice to add is some sort of minsize > parameter so that you could get a pixel or something marking the > existence of a data value for a grid point or a tiny arrowhead, sort of > like the current svn quiver behaves, but size settable. I tried adding > linewidths=(1,) to see if this would work. It sort of works, but looks > pretty ugly and I think confirms my suspicion that the problems I had > seen in my attempts were due to line stroking. > > Thanks and good work! > > Gary
Eric Firing wrote: > Gary, > > Thanks for the prompt test and report. > > I agree that the ability to put a dot at locations where arrows are > below a threshold would be good. I will add it. I think it should be > similar to a circle marker that scales with the arrow width, and has a > diameter that is a fraction of that width. That sounds like a good idea. > I also observed the stroking problem with small arrows and finite > linewidth. I haven't checked into it, but I am wondering whether the > problem is in the specification of the line join type. I suspect you're right about the join type. When I was building arrows out of LineCollections I had my suspicions that this was the problem. I didn't look into what control Agg gives you over this - there may not be an appropriate join type which always looks good. regards, Gary
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> arrow 1/50th the width of the plot. Change the window Eric> width, and the arrow length changes along with it. Zoom, Eric> and it does not change, however. In all cases, the arrow Eric> direction remains constant, regardless of window or view Eric> limit manipulations. (This is all because of John's Eric> transform magic--it is a little hard to understand at first, Eric> but it certainly provides wonderful functionality.) Hey someone said something nice about transforms! Eric, I haven't had a chance to try this code out but I did read through it and it looks very nice. A small comment: fig.dpi is already a Value, so I don't think you want + elif self.units == 'inches': + dpi = ax.figure.dpi.get() + dx = T.Value(dpi) because that is copy semantics and you probably want reference semantics + elif self.units == 'inches': + dx = ax.figure.dpi That way if someone changes the figure dpi. Or maybe I'm missing something and you really want copy. fig.dpi.set(72.) all of your transforms are automagically updated. Is there any reason not to commit this to svn? It seems to live in parallel with the existing quiver, so shouldn't cause anyone any grief. JDH JDH
>>>>> "John" == John Hunter <jdh...@ac...> writes: >>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> arrow 1/50th the width of the plot. Change the window Eric> width, and the arrow length changes along with it. Zoom, Eric> and it does not change, however. In all cases, the arrow Eric> direction remains constant, regardless of window or view Eric> limit manipulations. (This is all because of John's Eric> transform magic--it is a little hard to understand at first, Eric> but it certainly provides wonderful functionality.) John> Hey someone said something nice about transforms! John> Eric, I haven't had a chance to try this code out but I did John> read through it and it looks very nice. A small comment: John> fig.dpi is already a Value, so I don't think you want John> + elif self.units == 'inches': + dpi = ax.figure.dpi.get() + John> dx = T.Value(dpi) John> because that is copy semantics and you probably want John> reference semantics John> + elif self.units == 'inches': + dx = ax.figure.dpi John> That way if someone changes the figure dpi. Or maybe I'm John> missing something and you really want copy. John> fig.dpi.set(72.) John> all of your transforms are automagically updated. OK, let me try again. I added the "maybe I'm missing something" sentence after reading through my post in the wrong place and it totally garbled the meaning. What I meant to say was A small comment: fig.dpi is already a Value, so I don't think you want + elif self.units == 'inches': + dpi = ax.figure.dpi.get() + dx = T.Value(dpi) because that is copy semantics and you probably want reference semantics + elif self.units == 'inches': + dx = ax.figure.dpi That way if someone changes the figure dpi fig.dpi.set(72.) all of your transforms are automagically updated. Or maybe I'm missing something and you really want copy. JDH
> Hey someone said something nice about transforms! About time, isn't it! One thing I still don't understand: when is it necessary to bracket code with freeze/thaw? > > Eric, I haven't had a chance to try this code out but I did read > through it and it looks very nice. A small comment: fig.dpi is > already a Value, so I don't think you want > > + elif self.units == 'inches': > + dpi = ax.figure.dpi.get() > + dx = T.Value(dpi) > > because that is copy semantics and you probably want reference > semantics > > + elif self.units == 'inches': > + dx = ax.figure.dpi > > That way if someone changes the figure dpi. Or maybe I'm missing > something and you really want copy. You are right--the copy was a blatant bug, and I'm glad you caught it. > > fig.dpi.set(72.) > > all of your transforms are automagically updated. > > Is there any reason not to commit this to svn? It seems to live in > parallel with the existing quiver, so shouldn't cause anyone any > grief. > I was holding off so as not to confuse things by making a big change during a version release; Charlie indicated that this was his preference. Is the release packaging occurring today? If you want me to go ahead and commit, I am happy to do so. The idea would be that quiver2 is an experimental version, subject to more changes (e.g., addition of dots when arrows get too small; maybe changes in kwarg function and naming, if someone has better suggestions), but that it would replace the old quiver, perhaps at the next major release point. This is also Charlie's suggestion, and I agree with it. We need to clean things up occasionally, and not keep accumulating alternative versions of things. In that vein, can we drop pcolor_classic before the next major release? Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: >> Hey someone said something nice about transforms! Eric> About time, isn't it! Eric> One thing I still don't understand: when is it necessary to Eric> bracket code with freeze/thaw? It's never necessary, it's an optimization. Lots of objects share the ax.transData transform. When it is called to transform, all the lazy objects must be evaluated and lots of virtual function calls made. By "freezing" the transform, it will evaluate the lazy objects and compute and cache the components of the affine. Every freeze must be paired with a thaw, and only when you know the window resize, figure dpi, xlim settings, etc cannot occur in between the freeze and the thaw. The call to thaw releases the cached values. It is only helpful in a deeply nested call to draw with objects that share the same transformation, eg in Axes.draw. Eric> If you want me to go ahead and commit, I am happy to do so. It would help get more testers. I don't feel strongly either way Eric> it. We need to clean things up occasionally, and not keep Eric> accumulating alternative versions of things. In that vein, Eric> can we drop pcolor_classic before the next major release? As far as I am concerned, yes, but I suggest posting to the users list before dropping old functions to see how many people may still want them around. JDH
John Hunter wrote: >>>>>>"Eric" == Eric Firing <ef...@ha...> writes: > > > >> Hey someone said something nice about transforms! > > Eric> About time, isn't it! > > Eric> One thing I still don't understand: when is it necessary to > Eric> bracket code with freeze/thaw? > > It's never necessary, it's an optimization. Lots of objects share the > ax.transData transform. When it is called to transform, all the lazy > objects must be evaluated and lots of virtual function calls made. By > "freezing" the transform, it will evaluate the lazy objects and > compute and cache the components of the affine. Every freeze must be > paired with a thaw, and only when you know the window resize, figure > dpi, xlim settings, etc cannot occur in between the freeze and the > thaw. John, I don't understand how event handling works, so I am wondering: can we indeed be sure that window resize etc events are being blocked inside the freeze/thaw block in Axes.draw()? Are they blocked inside the entire draw method? What controls when a mouse event gets processed? Thanks. Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> I don't understand how event handling works, so I am Eric> wondering: can we indeed be sure that window resize etc Eric> events are being blocked inside the freeze/thaw block in Eric> Axes.draw()? Are they blocked inside the entire draw Eric> method? What controls when a mouse event gets processed? As far as I understand, GTK and other GUIs operate in a single thread, which means all the events they generate will be handled sequentially and not in parallel. Thus we can be sure that a call to draw will complete before the next one is called. But someone correct me if I'm wrong... What we try to avoid is having too many of these events pile up, so for example if a draw operation is expensive, lots of them can be queued and will be executing long after the resize is over. To avoid this, we use an idle draw handler in FigureCanvas.draw_idle. JDH