Re: [matplotlib-devel] News about new release?
On Sun, Apr 26, 2009 at 9:05 AM, Sandro Tosi mo...@debian.org wrote: Hi! some days ago there was a thread about new matplotlib release, but it seems there is some problem about windows binary pacakges preparation. Is this situation evolved a bit? Would it be considerable to do a source-only release (there are a lot of changes in the svn that our users would like to see), and then work on binary packages? Yes, we had problems with both the OSX and win32 builds, which we have not resolved yet unfortunately. The problem with a source only release is that on the sf download site, users will be directed to the latest release, and there will be no binaries available there. I suppose we could reupload the old binaries there, but I would prefer to et these issues resolved. I have had a crazy few weeks (first vacation, then my mom broke both her arms on vavation with me requiring surgery on both sides, and I've been spending time with her helping her recover), and I am just starting to get back into normal life here (meaning I'm behind on non-mpl things as well) JDH -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
The discussion about what to do with my patch fizzled. I created a decorator that made mixed-mode switching a one-line change per artist type. I also added get/set_rasterized and an _rasterized attribute to the Artist base class. I've used it on and off for a few months now with no noted bugs. If we don't like the decorator, we can just make a helper function that is called at the beginning of every artist.draw() method. It's not a very complicated modification. Would there be a case that draw methods of some Artists do not need to be decorated? Not that I can think of, if rasterization defaults to off and it's a user setting to turn it on (except perhaps some future modification where we auto-detect egregious poly counts in a mesh, for instance). If not, I guess some metaclass black magic might be not harmful. What do you think? I'm attaching modified version of your patch which utilize metaclass for decoration. I like that this solution doesn't litter every call to draw with rasterize checks. But it means that the rasterization support had better be robust, since Artist authors might not know they're interacting with the rasterization code. It has the downside of being implicit rather than explicit. I personally want that rasterization is also supported in the ps backend. I guess the missing support of alpha composition would be a problem. But, in most of the my use case, I want rasterization for artist with z lower than some specified value (i.e., background images using pcolormesh), so it is not a problem for me. I'm not too familiar with the PS backend, but I think that's separate from the issue of how to tell the renderer when to rasterize. Thanks, Eric Are you planning to commit your patch to the trunk? I'll be glad to help you if there are any issues. I'd love to get the patch in trunk, if only so that more people can try it out and find things to improve (or re-implement). Thanks, Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
