James Evans wrote: > All, > > I have been looking at some of the recent z-order changes and have found an > issue that breaks previous behavior. Previously when > items were added to a Figure or an Axes with the same z-order value, they > were rendered in order of when they were added, so that > the first one added is 'underneath' the others and the last one added is > rendered 'over' all the other items of the same z-order > value. This no longer is the case. The following snippet of code > demonstrates the problem: > > #=============================================================== > class ZSortClass( object ): > def __init__( self, name, zorder = 0 ): > self.name = name > self.zorder = zorder > def doit( self ): > print "z-order [%s] = %s" % (self.name, self.zorder) > > # Instantiate out of order to prove a point > a = ZSortClass( 'a', 0 ) > c = ZSortClass( 'c', 0 ) > b = ZSortClass( 'b', 0 ) > > all = [ a, b, c ] > dsu = [ (x.zorder, x.doit, x.name) for x in all ] > > print dsu > dsu.sort() > print dsu > #=============================================================== > > All three instances have the same 'zorder' value, which causes the sort > command to resort to sorting on the memory address. This > can change from run to run. In simple cases the memory addresses typically > increase in order of instantiation, but in larger blocks > of code, python can perform garbage collection at any time and this would no > longer hold true, and cause the effect to appear random > (This is also affecting the rendering of filled continents in basemap). I > couldn't think of an easy solution without making some > intrusive changes to what is already in place, so I thought that I'd post my > findings for further discussion. >
This is easy to fix by using the key kwarg (added in python 2.4) of the sort method, because python uses a stable sort. It looks like it only needs to be fixed in Axes.draw, because Figure.draw has never paid any attention to zorder anyway. I'll do it now. Eric > --James Evans > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
