On 09/07/2010 10:27 PM, Jae-Joon Lee wrote: > Eric, > > The drawing order of multiple axes in a same figure depends on the > order of "axes". And this has been the order that axes is added to the > figure (given that they have same zorder value). However, the current > implementation does not preserve this order. > > For example, > > > ax1 = axes([0.1, 0.1, 0.5, 0.5]) > ax2 = axes([0.4, 0.4, 0.5, 0.5]) > > draw() # ax2 on top of ax1 > > > sca(ax1) > draw() # ax2 underneath ax1 > > For some artist that spans multiple axes (e.g., an arrow connecting > two points in different axes), the drawing order of the axes is > important. We may manually adjust the zorder. Still. I think it is > better if Figure.axes preserves the order that axes are added.
Thanks for pointing this out. I will look into a modification to preserve that order. Probably it will involve storing a third element in each tuple, and sorting on that when generating the axes list. > > I believe this bug also affects the maintenance branch. Are you > planning to propagate this changes to the maint. branch also? No, my thinking is that the change I made is a bit too extensive for inclusion in the maintenance branch, and the priority for fixing the somewhat obscure 3D bug in that branch is low--especially given that the 3D code has many bugs (most of the current bugs on the tracker) and will most likely be reworked in the trunk over time. > > Besides, I think none of the matplotlib artist add itself to its > parent during the initialization. And, I think this is more of the > design choice, i.e., the artist instance is added to its parent > "after" the initialization. Anyhow, such distinction may not very > practical in the current implementation and I'm completely okay with > your changes (except the issues above). I don't think I understand the point you are making here--is it that the Axes3D is a lone anomaly? The main purpose of the changes I made was to clarify the tracking of axes by having them internally listed in only one data structure instead of always having to add or remove them from three separate structures. Fixing the 3D bug was a side-effect. Whether the changes I made were a net improvement, or a good design, remains debatable. Criticisms and suggestions for improvement or replacement are welcome. Eric > > Regards, > > -JJ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
