matplotlib-devel Mailing List for matplotlib

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
>