matplotlib-devel Mailing List for matplotlib (Page 8)

On Fri, May 09, 2008 at 10:57:09AM -0500, Paul Novak wrote:
> Hello,
> 
> I'm still interested in having a polygon symbol in the legend for a 
> scatter plot. I've made some changes to the suggestion of Manuel Metz to 
> make the legend symbol look better (the code-fragment from legend.py is 
> below). But when resizing the window, the symbol gets stretched and 
> placed in a bad location; it appears that the symbol is stretched and 
> scaled in the same manner as the legend box as a whole, while I think it 
> would look better if the symbol maintained the same size and aspect 
> ratio, but merely moved to the appropriate location within the resized 
> legend.
> 
> I would like to add this functionality, but I need some help to 
> understand the required transformations or scaling to make it look good. 
> Perhaps someone with a better understanding could provide some help?
Even better would be to let the legend be whatever size it needs to
be independent of the scale of the axes. I posted earlier on this
regarding units. 
Sorry, I won't have time to implement this myself.
	 - Paul

Eric Firing wrote:
> Michael Droettboom wrote:
>
>>> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu 
>>> feisty) chokes on the apostrophe in text, such as in table_demo and 
>>> one or two others. I think this is just a crazy bug in this version 
>>> of gs; you aren't having any such problems, are you? The problem 
>>> does not appear with cairo.ps output because it encodes the text 
>>> strings in some bizarre fashion.
>> Thanks. I've fixed this on the branch and trunk.
>
> Mike,
>
> Thank you--so, is this a workaround for a gs bug, or does the single 
> quote have some special meaning in postscript? When I first ran into 
> the problem I googled and looked at some PS documentation, and I 
> couldn't find anything indicating that the plain single quote 
> character as a literal was forbidden.
0x27 is fine as a literal, but it maps to "apostrophe", not 
"singlequote". The former isn't present in any of the Postscript tables 
of the fonts I looked at (Vera and the standard Windows fonts), so gs 
was crashing on the missing character. So, I just added a line to 
convert all apostrophes to singlequotes. Don't know if that's the right 
thing to do, but it works.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
>> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu 
>> feisty) chokes on the apostrophe in text, such as in table_demo and 
>> one or two others. I think this is just a crazy bug in this version 
>> of gs; you aren't having any such problems, are you? The problem does 
>> not appear with cairo.ps output because it encodes the text strings in 
>> some bizarre fashion.
> Thanks. I've fixed this on the branch and trunk.
Mike,
Thank you--so, is this a workaround for a gs bug, or does the single 
quote have some special meaning in postscript? When I first ran into 
the problem I googled and looked at some PS documentation, and I 
couldn't find anything indicating that the plain single quote character 
as a literal was forbidden.
Eric

Hello,
I'm still interested in having a polygon symbol in the legend for a 
scatter plot. I've made some changes to the suggestion of Manuel Metz to 
make the legend symbol look better (the code-fragment from legend.py is 
below). But when resizing the window, the symbol gets stretched and 
placed in a bad location; it appears that the symbol is stretched and 
scaled in the same manner as the legend box as a whole, while I think it 
would look better if the symbol maintained the same size and aspect 
ratio, but merely moved to the appropriate location within the resized 
legend.
I would like to add this functionality, but I need some help to 
understand the required transformations or scaling to make it look good. 
Perhaps someone with a better understanding could provide some help?
Thanks,
Paul Novak
 elif isinstance(handle, RegularPolyCollection):
 if self.numpoints == 1:
 xdata = np.array([left])
 for path in handle.get_paths():
 xy = path.vertices
 p = Polygon(xy)
 x = min(xdata)
 y = y-0.5*HEIGHT
# 0.35 * HEIGHT makes the legend symbol an appropriate size.
# patch_aspect scales the legend symbol to the appropriate aspect ratio.
 patch_aspect = (max(xy[:,0]) - min(xy[:,0])) / 
(max(xy[:,1]) - min(xy[:,1]))
 bbox = Bbox.from_bounds(x, y, 0.35 * HEIGHT, 0.35 * 
HEIGHT * patch_aspect)
 p.set_facecolor(handle._facecolors[0])
 if handle._edgecolors != 'None':
 p.set_edgecolor(handle._edgecolors[0])
 self._set_artist_props(p)
# HERE IS THE ADDITIONAL TRANSFORM FOR THE POLY
 p.set_transform( BboxTransformTo(bbox) + 
p.get_transform() )
 p.set_clip_box(None)
 p.set_clip_path(None)
 ret.append(p)

Eric Firing wrote:
> John Hunter wrote:
>> On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> 
>> wrote:
>>
>>> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were 
>>> trying
>>> to deal with something more specific to Postscript. Here's the 
>>> commit note:
>>>
>>> "Alternative fix for ps backend bug; removes superfluous 
>>> gsave/grestores."
>>
>> That's the one I am referring to also -- we started talking about some
>> dpi related problems in the thread I referred to and meandered over to
>> this other bug, which was caused by the draw_ps code not properly
>> doing a gsave/restore wrapper if the object did not have a cliprect or
>> a clippath. It was exposed by the quiver key object, which has a
>> collection that uses offsets and no clipping. Eric and I separately
>> committed a patch to make sure gsave/grestore was being called, but
>> his was cleaner so his was the final version. But apparently
>> something was left out...
>
> Yes, I misunderstood something in the original version. I *think* I 
> have it all straightened out now.
Looks good here.
>
> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu 
> feisty) chokes on the apostrophe in text, such as in table_demo and 
> one or two others. I think this is just a crazy bug in this version 
> of gs; you aren't having any such problems, are you? The problem does 
> not appear with cairo.ps output because it encodes the text strings in 
> some bizarre fashion.
Thanks. I've fixed this on the branch and trunk.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote:
> 
>> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying
>> to deal with something more specific to Postscript. Here's the commit note:
>>
>> "Alternative fix for ps backend bug; removes superfluous gsave/grestores."
> 
> That's the one I am referring to also -- we started talking about some
> dpi related problems in the thread I referred to and meandered over to
> this other bug, which was caused by the draw_ps code not properly
> doing a gsave/restore wrapper if the object did not have a cliprect or
> a clippath. It was exposed by the quiver key object, which has a
> collection that uses offsets and no clipping. Eric and I separately
> committed a patch to make sure gsave/grestore was being called, but
> his was cleaner so his was the final version. But apparently
> something was left out...
Yes, I misunderstood something in the original version. I *think* I 
have it all straightened out now.
I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu 
feisty) chokes on the apostrophe in text, such as in table_demo and one 
or two others. I think this is just a crazy bug in this version of gs; 
you aren't having any such problems, are you? The problem does not 
appear with cairo.ps output because it encodes the text strings in some 
bizarre fashion.
Eric

I forgot to mention -- A handful of SVG examples (polar_demo.py, 
specgram_demo.py) cause my Firefox 2.0.0.14 on RHEL4 to crash. These 
same files read fine in Inkscape 0.46. AFAICT, there is some sort of 
limit on the number of vertices in a path, as shortening them does help, 
but I couldn't find a reference to this bug online. Unfortunately, 
given that a path could be a closed polygon, simply chunking the path 
data into multiple elements isn't good enough. So a general solution 
will be tricky. I don't think this is worth holding off on the beta 
release (0.91.x has this same problem), but it's something to be aware of.
Cheers,
Mike
Michael Droettboom wrote:
> The SVG examples all look good now, as does PDF and Agg (unless I'm 
> missing some small details in my quick scanning of the images).
>
> The problem with quadmesh_demo in the Ps backend seems to have been 
> introduced by r5082. r5081 (on backend_ps.py alone) seems to work, 
> with the exception that strokes are being drawn around the masked-out 
> quads. (That's an easy bug to fix, however -- just return early from 
> _draw_ps if "stroke" and "fill" are both false).
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082 
>
>
> Since I don't recall the issues that r5802/r5803 were trying to solve, 
> I'm hoping that one of you could have a look at this and have a better 
> idea where it's going wrong...
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>> I'm making some progress on SVG -- all issues I've seen so far seem 
>> to be related to clipping. I'll let you know how it goes. Just a 
>> heads up to delay the release for now (unless I come across something 
>> that doesn't look like it can be fixed in a short amount of time.)
>>
>> Cheers,
>> Mike
>>
>> Eric Firing wrote:
>> 
>>> John Hunter wrote:
>>> 
>>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> 
>>>> wrote:
>>>>
>>>> 
>>>>> Getting out a 0.98 beta soon would help in getting it more widely
>>>>> tested, but it would be nice if that first beta passed the basic 
>>>>> checks
>>>>> of working for all backend_driver tests on all the standard 
>>>>> backends.
>>>>> As of the last time I looked, this was not the case.
>>>>> 
>>>> both the branch and the trunk are running w/o error on my system. The
>>>> branch is issuing some warnings related to the new hist changes.
>>>>
>>>> JDH
>>>> 
>>> They run, but the trunk does not make valid plots in all cases. 
>>> Many things are fouled up in SVG. The quadmesh_demo.ps is broken. 
>>> I have not checked pdf.
>>>
>>> Eric
>>> 
>>
>> 
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote:
> 
>> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying
>> to deal with something more specific to Postscript. Here's the commit note:
>>
>> "Alternative fix for ps backend bug; removes superfluous gsave/grestores."
> 
> That's the one I am referring to also -- we started talking about some
> dpi related problems in the thread I referred to and meandered over to
> this other bug, which was caused by the draw_ps code not properly
> doing a gsave/restore wrapper if the object did not have a cliprect or
> a clippath. It was exposed by the quiver key object, which has a
> collection that uses offsets and no clipping. Eric and I separately
> committed a patch to make sure gsave/grestore was being called, but
> his was cleaner so his was the final version. But apparently
> something was left out...
> 
> JDH
Right. I will look at, today if at all possible.
Eric

On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <md...@st...> wrote:
> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were trying
> to deal with something more specific to Postscript. Here's the commit note:
>
> "Alternative fix for ps backend bug; removes superfluous gsave/grestores."
That's the one I am referring to also -- we started talking about some
dpi related problems in the thread I referred to and meandered over to
this other bug, which was caused by the draw_ps code not properly
doing a gsave/restore wrapper if the object did not have a cliprect or
a clippath. It was exposed by the quiver key object, which has a
collection that uses offsets and no clipping. Eric and I separately
committed a patch to make sure gsave/grestore was being called, but
his was cleaner so his was the final version. But apparently
something was left out...
JDH

John Hunter wrote:
> On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <md...@st...> wrote:
> 
>> The SVG examples all look good now, as does PDF and Agg (unless I'm missing
>> some small details in my quick scanning of the images).
>>
>> The problem with quadmesh_demo in the Ps backend seems to have been
>> introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with the
>> exception that strokes are being drawn around the masked-out quads. (That's
>> an easy bug to fix, however -- just return early from _draw_ps if "stroke"
>> and "fill" are both false).
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082
>>
>> Since I don't recall the issues that r5802/r5803 were trying to solve, I'm
>> hoping that one of you could have a look at this and have a better idea
>> where it's going wrong...
>> 
>
> Eric and I were simultaneously working on a bug described in the
> thread "dpi-related positioning errors in Agg savefig" and ended up
> communicating off list. He committed the final fix, so perhaps Eric
> you could look at this and see where the logic needs to be updated.
>
> 
Sorry, I mistyped -- it's r5082/r5083. I think those revisions were 
trying to deal with something more specific to Postscript. Here's the 
commit note:
"Alternative fix for ps backend bug; removes superfluous gsave/grestores."
Cheers,
Mike
>
> 
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> I'm making some progress on SVG -- all issues I've seen so far seem to be
>>> related to clipping. I'll let you know how it goes. Just a heads up to
>>> delay the release for now (unless I come across something that doesn't look
>>> like it can be fixed in a short amount of time.)
>>>
>>> Cheers,
>>> Mike
>>>
>>> Eric Firing wrote:
>>>
>>> 
>>>> John Hunter wrote:
>>>>
>>>> 
>>>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
>>>>>
>>>>>
>>>>> 
>>>>>> Getting out a 0.98 beta soon would help in getting it more widely
>>>>>> tested, but it would be nice if that first beta passed the basic
>>>>>> checks
>>>>>> of working for all backend_driver tests on all the standard backends.
>>>>>> As of the last time I looked, this was not the case.
>>>>>>
>>>>>> 
>>>>> both the branch and the trunk are running w/o error on my system. The
>>>>> branch is issuing some warnings related to the new hist changes.
>>>>>
>>>>> JDH
>>>>>
>>>>> 
>>>> They run, but the trunk does not make valid plots in all cases. Many
>>>> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have not
>>>> checked pdf.
>>>>
>>>> Eric
>>>>
>>>> 
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <md...@st...> wrote:
> The SVG examples all look good now, as does PDF and Agg (unless I'm missing
> some small details in my quick scanning of the images).
>
> The problem with quadmesh_demo in the Ps backend seems to have been
> introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with the
> exception that strokes are being drawn around the masked-out quads. (That's
> an easy bug to fix, however -- just return early from _draw_ps if "stroke"
> and "fill" are both false).
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082
>
> Since I don't recall the issues that r5802/r5803 were trying to solve, I'm
> hoping that one of you could have a look at this and have a better idea
> where it's going wrong...
Eric and I were simultaneously working on a bug described in the
thread "dpi-related positioning errors in Agg savefig" and ended up
communicating off list. He committed the final fix, so perhaps Eric
you could look at this and see where the logic needs to be updated.
JDH
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>>
>> I'm making some progress on SVG -- all issues I've seen so far seem to be
>> related to clipping. I'll let you know how it goes. Just a heads up to
>> delay the release for now (unless I come across something that doesn't look
>> like it can be fixed in a short amount of time.)
>>
>> Cheers,
>> Mike
>>
>> Eric Firing wrote:
>>
>>>
>>> John Hunter wrote:
>>>
>>>>
>>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
>>>>
>>>>
>>>>>
>>>>> Getting out a 0.98 beta soon would help in getting it more widely
>>>>> tested, but it would be nice if that first beta passed the basic
>>>>> checks
>>>>> of working for all backend_driver tests on all the standard backends.
>>>>> As of the last time I looked, this was not the case.
>>>>>
>>>>
>>>> both the branch and the trunk are running w/o error on my system. The
>>>> branch is issuing some warnings related to the new hist changes.
>>>>
>>>> JDH
>>>>
>>>
>>> They run, but the trunk does not make valid plots in all cases. Many
>>> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have not
>>> checked pdf.
>>>
>>> Eric
>>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

The SVG examples all look good now, as does PDF and Agg (unless I'm 
missing some small details in my quick scanning of the images).
The problem with quadmesh_demo in the Ps backend seems to have been 
introduced by r5082. r5081 (on backend_ps.py alone) seems to work, with 
the exception that strokes are being drawn around the masked-out quads. 
(That's an easy bug to fix, however -- just return early from _draw_ps 
if "stroke" and "fill" are both false).
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5082
Since I don't recall the issues that r5802/r5803 were trying to solve, 
I'm hoping that one of you could have a look at this and have a better 
idea where it's going wrong...
Cheers,
Mike
Michael Droettboom wrote:
> I'm making some progress on SVG -- all issues I've seen so far seem to 
> be related to clipping. I'll let you know how it goes. Just a heads up 
> to delay the release for now (unless I come across something that 
> doesn't look like it can be fixed in a short amount of time.)
>
> Cheers,
> Mike
>
> Eric Firing wrote:
> 
>> John Hunter wrote:
>> 
>>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
>>>
>>> 
>>>> Getting out a 0.98 beta soon would help in getting it more widely
>>>> tested, but it would be nice if that first beta passed the basic 
>>>> checks
>>>> of working for all backend_driver tests on all the standard backends.
>>>> As of the last time I looked, this was not the case.
>>>> 
>>> both the branch and the trunk are running w/o error on my system. The
>>> branch is issuing some warnings related to the new hist changes.
>>>
>>> JDH
>>> 
>> They run, but the trunk does not make valid plots in all cases. Many 
>> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have 
>> not checked pdf.
>>
>> Eric
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm making some progress on SVG -- all issues I've seen so far seem to 
be related to clipping. I'll let you know how it goes. Just a heads up 
to delay the release for now (unless I come across something that 
doesn't look like it can be fixed in a short amount of time.)
Cheers,
Mike
Eric Firing wrote:
> John Hunter wrote:
>> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
>>
>>> Getting out a 0.98 beta soon would help in getting it more widely
>>> tested, but it would be nice if that first beta passed the basic 
>>> checks
>>> of working for all backend_driver tests on all the standard backends.
>>> As of the last time I looked, this was not the case.
>>
>> both the branch and the trunk are running w/o error on my system. The
>> branch is issuing some warnings related to the new hist changes.
>>
>> JDH
>
> They run, but the trunk does not make valid plots in all cases. Many 
> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have 
> not checked pdf.
>
> Eric
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Personally, I like the use of decorators for this -- it seems to be a nice
clean tool for the job -- but it could be controversial. Fortunately, this
is a nice self-contained usage that could be considered an experimental
foray into decorators, and it doesn't affect outward-facing code.
As for a mechanism to register before/after draw callbacks, I think what
you've done already certainly paves the way for that. Callbacks in general
are something that we've looked at using Enthought Traits for. I don't know
if that's applicable here, but I would be nice to use something general and
consistent for all callbacks in mpl so they all look and behave the same.
Since we haven't really settled on that, it's no major shortcoming that your
patch doesn't address that yet. It will now be much easier when we do.
(And yes, it was only the start/stop rendering pair in QuadMesh that I was
referring to pulling out.)
Thanks,
Mike
Eric Bruning wrote:
> I've added get/set_rasterized in Artist.
>
> The decorator is called @hook_before_after_draw. I wanted to put in a
> mechanism that allowed for registration of before/after draw
> callbacks, but couldn't figure out how. Might still be possible with
> some decorator magic that I don't understand. Each artist with a
> draw(self, renderer) method has been decorated.
>
> I pulled out the start/stop rendering pair in QuadMesh. I presume
> those two lines were all I needed to touch. I'll assume so unless I
> hear otherwise.
>
> Patch at:
> http://deeplycloudy.com/patches/20080507-mpl-mixed-mode-decorator-r5110.diff
>
> (I moved the patch mentioned at the beginning of this thread into the
> patches directory as well.)
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm available to crank out some builds. I'll keep my eyes peeled for the
new numpy.
- Charlie
On Wed, May 7, 2008 at 1:21 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 7, 2008 at 10:59 AM, Darren Dale <dar...@co...>
> wrote:
>
> > I'm also in favor of a 0.98 release. Calling it beta is fine, I just
> need
> > something other than svn to which I can point my users.
>
> I happy with both -- doing a 0.91.3 maintenance release and a
> 0.98.beta release. We don't have to do them at the same time, but it
> might be easier. Charlie?
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save 100ドル.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John Hunter wrote:
> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
> 
>> Getting out a 0.98 beta soon would help in getting it more widely
>> tested, but it would be nice if that first beta passed the basic checks
>> of working for all backend_driver tests on all the standard backends.
>> As of the last time I looked, this was not the case.
> 
> both the branch and the trunk are running w/o error on my system. The
> branch is issuing some warnings related to the new hist changes.
> 
> JDH
They run, but the trunk does not make valid plots in all cases. Many 
things are fouled up in SVG. The quadmesh_demo.ps is broken. I have 
not checked pdf.
Eric

On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
> Getting out a 0.98 beta soon would help in getting it more widely
> tested, but it would be nice if that first beta passed the basic checks
> of working for all backend_driver tests on all the standard backends.
> As of the last time I looked, this was not the case.
both the branch and the trunk are running w/o error on my system. The
branch is issuing some warnings related to the new hist changes.
JDH

I've added get/set_rasterized in Artist.
 The decorator is called @hook_before_after_draw. I wanted to put in a
 mechanism that allowed for registration of before/after draw
 callbacks, but couldn't figure out how. Might still be possible with
 some decorator magic that I don't understand. Each artist with a
 draw(self, renderer) method has been decorated.
 I pulled out the start/stop rendering pair in QuadMesh. I presume
 those two lines were all I needed to touch. I'll assume so unless I
 hear otherwise.
 Patch at:
 http://deeplycloudy.com/patches/20080507-mpl-mixed-mode-decorator-r5110.diff
 (I moved the patch mentioned at the beginning of this thread into the
 patches directory as well.)

John and Michael,
 Thanks for your detailed feedback about the mpl design philosophy. I'm
 not attached to my implementation details. I will scrap the
 draw_raster list and move to implement get/set_rasterized on the
 artists.
 > > Doing this in the axes.draw method may not be the most natural place
 > > to do this since it could be done in the artist.draw method, but it
 > > may be the most expedient. This is an area where having support for
 > > before_draw and after_draw hooks might be useful.
 How about providing a decorator for the draw method that would do the
 necessary check/start/draw/stop? Requires Python 2.4 for the nice
 syntax, but can still be done with 2.3. A decorator would make adding
 the rasterize feature (and others) quite easy for any draw method.
 There are several draw methods in the chain (figure has one, axes has
 one, and line, collections, etc. all do), and this would be a fast,
 low-maintenance way of adding hooks to each artist subclass (I count
 16 2D draw methods). I have a proof-of-concept snippet if it would be
 helpful to understand what I mean.
 > > One potential
 > > problem with either of these approached is it looks like the mixed
 > > mode renderer is set up to handle multiple rasterized draws before
 > > dumping the aggregate image into the backend on a stop_renderer, so
 > > doing the start/stop in any of the approaches above would obviate this
 > > efficiency.
 > > The axes could aggregate the rasterized artists before
 > > rendering and then do them all together, but making this play properly
 > > with zorder will be tricky.
 > >
 > That's right. To receive significant gains, you would generally want to
 > perform a number of drawing operations in a single raster buffer. Given how
 > mpl is currently designed, that generally implies a Collection (which is
 > fairly easy to wrap start/stop_rasterizing calls around) -- it doesn't
 > necessarily have to mean a whole bunch of separate Artist objects (which
 > would be much harder to do given the current way things are drawn). The
 > latter may be ultimately more optimal, but the former is an easy win.
 >
 >
> As for the implementation, Eric's patch does appear to deal with the
 > z-order problem, (by interleaving rasterized and non-rasterized drawing
 > correctly base on zorder), but it doesn't combine adjacent rasterized
 > artists into a single buffer. The drawing loop in Axes.draw could fairly
 > easily be modified to do that. However, I think a better solution that
 > doesn't require an explicit "draw_raster" list, is to make
 > "stop_rasterizing" lazy. At the moment, when "stop_rasterizing" is called,
 > the buffer is immediately flushed and written out. If instead it just set a
 > flag, causing the buffer to be flushed when the next vector object is
 > written, then something like
 >
 > start_rasterizing()
 > draw_line()
 > stop_rastering()
 > start_rastering()
 > draw_line()
 > stop_rasterizing()
 > draw_line()
 >
 > would write out a single raster buffer with two lines, followed by a vector
 > line. Of course, and here is the tricky bit, if the two rasterized objects
 > are really far apart spatially, you waste a lot of space on transparent
 > pixels between them. We can let the user decide whether to rasterize each
 > individually with a nice clean API, but letting the user decide whether to
 > combine adjacent rasterizations gets tricky and I think is asking too much
 > of someone who doesn't know the mpl internals. Perhaps that is an argument
 > against trying to implicitly combine adjacent rasterized draws -- it's
 > trying to be too smart?
 >
 I see the inefficiency in repeated start/stop/flush. At the same
 time, generating a separate image in each start/stop is useful for
 later tweaking/composition in a vector drawing editor. For instance,
 if I overlay points (sometimes 10^5) on top of weather radar data
 (10^5 polys), I might want to turn the points off. So I'd argue that
 flush-per-artist is best because it creates a figure with maximal
 editability, which is one of the advantages of using a vector-based
 backend in the first place.
 In summary:
 1. On the artist base class, add get/set_rasterized( True | False | None )
 with the default for True to be rasterize-per-artist. Later (or now,
 if it's important to others), ('alone' | 'combine') could be added,
 with True defaulting to 'alone'.
 2. Starting / stopping the rasterizing:
> > if a.get_rasterized():
 > > renderer.start_rasterizing()
 > > a.draw(renderer)
 > > renderer.stop_rasterizing()
 > > else:
 > > a.draw(renderer)
 Put this in a draw method decorator. Decorate each artist subclass
individually.
 -Eric

Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended 
> stable release. (Just today, Matthias Michler pointed out a pretty 
> significant bug with widgets related to the refactoring). I think a 
> 0.98 release that is clearly labeled as beta would not be a bad thing to 
> get it in the hands of more people who don't track SVN.
> 
Getting out a 0.98 beta soon would help in getting it more widely 
tested, but it would be nice if that first beta passed the basic checks 
of working for all backend_driver tests on all the standard backends. 
As of the last time I looked, this was not the case.
Eric

On Wed, May 7, 2008 at 10:59 AM, Darren Dale <dar...@co...> wrote:
> I'm also in favor of a 0.98 release. Calling it beta is fine, I just need
> something other than svn to which I can point my users.
I happy with both -- doing a 0.91.3 maintenance release and a
0.98.beta release. We don't have to do them at the same time, but it
might be easier. Charlie?
JDH

On Wednesday 07 May 2008 11:18:22 am Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended
> stable release. (Just today, Matthias Michler pointed out a pretty
> significant bug with widgets related to the refactoring). I think a
> 0.98 release that is clearly labeled as beta would not be a bad thing to
> get it in the hands of more people who don't track SVN.
I'm also in favor of a 0.98 release. Calling it beta is fine, I just need 
something other than svn to which I can point my users.
Darren

Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended 
> stable release. (Just today, Matthias Michler pointed out a pretty 
> significant bug with widgets related to the refactoring). I think a 
> 0.98 release that is clearly labeled as beta would not be a bad thing 
> to get it in the hands of more people who don't track SVN.
>
> I think a 0.91.3 release is probably also in order, since there are 23 
> bugfixes, most notably the wx saving bug. I think that release is 
> important to push bugfixes out to distributions that already package 
> 0.91.2 (e.g. Ubuntu Hardy).
>
> And as for the egg issue (which I'm completely ignorant of) -- is that 
> something that could be fixed on 0.91.x without too much trouble? Is 
> it something that once worked and is now broken?
>
> Cheers,
> Mike
Mike: The egg issue required renaming matplotlib.toolkits to 
mpl_toolkits. We discussed this at the time, and decided it would cause 
too much code breakage to be included in 0.91.x.
I'm OK with a 0.98 beta, but that's more work for Charlie to make extra 
installers and eggs.
-Jeff
>
> Jeff Whitaker wrote:
>> What do people think of releasing 0.98 after numpy 1.1 is released 
>> this weekend?
>> The main reason I'd like to do this (instead of releasing another 
>> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
>> installed as an egg basemap (or any other toolkit) cannot be installed.
>>
>> -Jeff
>>
>> 
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I don't know if 0.98 has seen enough hammering to be a recommended 
stable release. (Just today, Matthias Michler pointed out a pretty 
significant bug with widgets related to the refactoring). I think a 
0.98 release that is clearly labeled as beta would not be a bad thing to 
get it in the hands of more people who don't track SVN.
I think a 0.91.3 release is probably also in order, since there are 23 
bugfixes, most notably the wx saving bug. I think that release is 
important to push bugfixes out to distributions that already package 
0.91.2 (e.g. Ubuntu Hardy).
And as for the egg issue (which I'm completely ignorant of) -- is that 
something that could be fixed on 0.91.x without too much trouble? Is it 
something that once worked and is now broken?
Cheers,
Mike
Jeff Whitaker wrote:
> What do people think of releasing 0.98 after numpy 1.1 is released this 
> weekend? 
>
> The main reason I'd like to do this (instead of releasing another 
> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
> installed as an egg basemap (or any other toolkit) cannot be installed.
>
> -Jeff
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

What do people think of releasing 0.98 after numpy 1.1 is released this 
weekend? 
The main reason I'd like to do this (instead of releasing another 
0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
installed as an egg basemap (or any other toolkit) cannot be installed.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg