matplotlib-devel Mailing List for matplotlib (Page 4)

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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.
> 
Try svn 8000. I think it fixes the problem in Axes and Figure.
Eric

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.
--James Evans

On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...> wrote:
> Hi all,
>
> I would like to contribute to matplotlib with this enhancement for the
> PyQt4 backend: the idea is to add a toolbar button to configure figure
> options (axes, curves, ...).
>
> It's based on a tiny module called formlayout to generate PyQt4 form
> dialog automatically.
>
> Some screenshots:
> http://code.google.com/p/formlayout/
>
> So, if you're interested (all the following is GPL2):
>
> *matplotlib patch*
Would you please submit an actual patch? I don't know exactly where
you intend these changes to be placed.
> In FigureManagerQT.__init__, added:
> self.canvas.axes = self.canvas.figure.add_subplot(111)
What is the purpose of this change? What if I didn't want such an axes
on my canvas? What if I want to layout my own axes([.2,.2,.75,.75]) or
add_subplot(311)? I don't think these changes can be accepted in the
current form, they don't appear to integrate well with the standard
behavior of the library.
> In NavigationToolbar2QT._init_toolbar, added:
> a = self.addAction(self._icon("customize.png"), 'Customize',
> self.edit_parameters)
> a.setToolTip('Edit curves line and axes parameters')
>
> Added the following method in NavigationToolbar2QT:
> def edit_parameters(self):
>  from figureoptions import figure_edit
>  figure_edit(self.canvas, self)
>
> *additionnal modules and data*
>
> formlayout.py (http://code.google.com/p/formlayout/)
> figureoptions.py (http://code.google.com/p/PyQtShell/)
> customize.png (http://code.google.com/p/PyQtShell/)
Darren