I also committed a small patch that makes zorders respected among images (not with other artists) for noncomposit backends.
Anyhow, can we get rid of the second items in the "dsu" list? My guess is that this is to make the sort stable, but python sort is already stable, isn't it? -JJ On Tue, Nov 10, 2009 at 4:06 PM, Andrew Straw <straw...@astraw.com> wrote: > Andrew Straw wrote: >> John Hunter wrote: >> >>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <straw...@astraw.com> wrote: >>> >>> >>>> Hi All, >>>> >>>> I have addressed what I think is a long-standing wart: zorder is mostly >>>> ignored for imshow(). (See e.g. >>>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 >>>> ) The question is whether I should apply the attached patch. >>>> > I went ahead and committed this patch to the trunk in r7950. > > Here's the CHANGELOG entry: > > 2009-11-10 Single images, and all images in renderers with > option_image_nocomposite (i.e. agg, macosx and the svg > backend when rcParams['svg.image_noscale'] is True), are > now drawn respecting the zorder relative to other > artists. (Note that there may now be inconsistencies across > backends when more than one image is drawn at varying > zorders, but this change introduces correct behavior for > the backends in which it's easy to do so.) > > Jae Joon raised a couple of concerns: > > 1) the patch would introduces inconsistent behavior between backends -- > namely that PS and other backends, when given more than one image, would > "composite" (or rasterize) all images and stick them underneath > everything else. Agg would have proper zordering between images and > other artists. > > 2) there is doubt about the utility of such functionality. Jae-Joon says > "I think it is often sufficient if we draw images at the bottom but > respect zorders among images". > > As for #1, it seems to me this is simply a bug/limitation with the > compositing functionality (e.g. the PS backend). The SVG backend has the > possibility to turn compositing on or off based on the svg.image_noscale > rcParam, and perhaps other backends could grow something similar. I > can't see why this patch -- that specifically solves the bug/limitation > in the backends where its easily possible -- should be held back due to > this. > > As for #2, perhaps my use case will be convincing -- I'm trying to draw > reconstructions of various experimental setups, and the easiest way to > do this is to create texture-mapped rectangles in which I can control > the zorder -- a single texture may need to be over some artists but > under others. Perhaps there's an easier way to achieve this, but I'm not > aware of it. > > Jae Joon has also stated that he's OK with the patch, so I went ahead > and committed it. In light of all this, please let me know if you still > have concerns, and hopefully they can be addressed. In the worst case, > we can back this patch out. > > -Andrew > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
