matplotlib-devel Mailing List for matplotlib (Page 5)

On Nov 20, 2007 11:24 AM, Rob Hetland <he...@ta...> wrote:
> 2007年11月20日 18:13:23.074 Python[24184] *** _NSAutoreleaseNoPool():
> Object 0x409e190 of class NSCarbonWindowContentView autoreleased with
> no pool in place - just leaking
I googled this message and found this:
http://www.cocoabuilder.com/archive/message/cocoa/2004/6/25/110592
I think we are going to need some help from a cocoa person.... I CCd
Charlie, who did some of the work on the cocoa agg backend...
JDH

I'm not sure that this consumes enough cycles to warrant the additional 
complexity of doing things differently on a per-backend basis (the 
choice to stick with 8-bit colors would have to be made higher than the 
backend to see any savings). The pcolor images are an exception, since 
that code is common to all backends -- we can do whatever works best.
To see what the "upper limit" on the performance increase would be, I 
modified draw_quad_mesh in the Agg backend so that it doesn't look up or 
multiply colors at all (it just uses a hard-coded 8-bit black always), 
and on the included pcolormesh benchmark, there was no significant 
difference (I ran each 3 times, since the difference is so small):
trunk:
	5.518 fps
	5.530 fps
	5.530 fps
trunk (hard-coded color):
	5.507 fps
	5.567 fps
	5.302 fps
I did notice, however, that draw_quad_mesh makes an unnecessary 
temporary buffer to convert the floating-point colors to 8-bit color. 
Since each color is only converted once, it is slightly faster to do the 
conversion on the fly and avoid the heap alloc/dealloc.
trunk (no alloc):
	5.630 fps
	5.618 fps
	5.617 fps
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> I think I'm a little confused by the question. From the Python
>> perspective, everything in the Agg backend takes floats. Agg
>> actually has color types for both floating point and 8-bit-per-plane
>> colors, though obviously it's converted to 8-bit-per-plane
>> eventually. But, of course, that is done on the fly without much
>> memory copying, so I'm quite surprised that the speed up is
>> significant... Where exactly is this conversion happening, and how
>> are you now avoiding it? (Is this in code that is not checked in,
>> perhaps?)
> 
> I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. 
> Both work directly with agg::rgba8, and can benefit from doing a color 
> table lookup directly in 8-bit space instead of using floats and then 
> converting.
> 
> Eric
> 
>>
>> As for the other backends, it's a mixed bag. PDF, PS and Cairo want
>> floats, SVG wants ints. Personally, I just *like* floats better, as
>> it feels more future proof, even though most people aren't using the
>> extra color resolution now. (Of course, if your plot relies on
>> high-resolution color, you probably need to rethink your plot
>> anyway... ;)
>>
>> Cheers, Mike
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> It made my merge from trunk to branch a little harder than it had to be, 
> too.
> 
> I understand the drive for this, but there is that downside as well.
John, Mike,
Yes, I understand, and I am sorry--but I hope it is one-time pain to 
avoid continuing pin-pricks. If svn ignored trailing whitespace, then 
there would be no problem; I could continue to use an editor that 
removes it, and you could continue to use editors that gratuitously add 
it, and usually it would make no difference. This is not the case, 
however. As it is now, if a file comes into svn without any trailing 
whitespace, and one of you loads it up, maybe makes a trivial change 
after running your cursor through it, and saves it--it will end up with 
a big changeset--lots of trailing whitespace. This is just plain bad. 
All downside, no upside.
Eric
> 
> Cheers,
> Mike
> 
> John Hunter wrote:
>> On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>>> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
>>>> Trailing whitespace introduces noise--sometimes a *lot* of noise--into
>>>> svn changesets. I would very much appreciate it if everyone would try
>>>> to eliminate trailing whitespace before committing any changes to svn.
>>>> (And also eliminate hard tabs--I haven't seen many new ones creeping 
>>>> in,
>>>> but continuing vigilence is appreciated.)
>>
>> While I'm happy to play along ( I configured my emacs to detect
>> whitespace) and suspect I may have been a trailing whitespace
>> contributer, I fear this may be a case where the cure is worse than
>> the disease. As we all make commits to fix the trailing whitespaces,
>> since they are now glaringly ugly in my emacs buffer, I fear we will
>> see significantly more changesets which are whitespace only, than if
>> we simply configured our editors to ignore them.
>>
>> JDH
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

It made my merge from trunk to branch a little harder than it had to be, 
too.
I understand the drive for this, but there is that downside as well.
Cheers,
Mike
John Hunter wrote:
> On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
>>> Trailing whitespace introduces noise--sometimes a *lot* of noise--into
>>> svn changesets. I would very much appreciate it if everyone would try
>>> to eliminate trailing whitespace before committing any changes to svn.
>>> (And also eliminate hard tabs--I haven't seen many new ones creeping in,
>>> but continuing vigilence is appreciated.)
> 
> While I'm happy to play along ( I configured my emacs to detect
> whitespace) and suspect I may have been a trailing whitespace
> contributer, I fear this may be a case where the cure is worse than
> the disease. As we all make commits to fix the trailing whitespaces,
> since they are now glaringly ugly in my emacs buffer, I fear we will
> see significantly more changesets which are whitespace only, than if
> we simply configured our editors to ignore them.
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

On Nov 20, 2007, at 5:09 PM, John Hunter wrote:
> Are you on this box now to verify the problem? There was a bug in
> keypress_demo, because the demo was using 'g' to turn the grid on and
> off and the default key interaction was doing the same, resulting in a
> double toggle and no change. I fixed this bug in svn. I looked
> through the diffs from r3393 to present and cannot find anything which
> explains the difference.
>
> I'm assuming that some of the other key events (eg press 'x' when
> panning to constrain the zoom to the x axis) are also failing. And
> you have the window focus (click on the subplot) when testing...
So I re-installed from the latest SVN, and can re-confirm that 
keypress events do not work. I also noticed that this error message 
shows up (the one you allude to above):
2007年11月20日 18:13:23.074 Python[24184] *** _NSAutoreleaseNoPool(): 
Object 0x409e190 of class NSCarbonWindowContentView autoreleased with 
no pool in place - just leaking
This error message does _not_ appear when I revert back to the 
2007年11月7日 version where keypress events work. I am not sure if they 
are related, but it seems likely. This error shows up when a figure 
is created (I used ipython and debug-annoying, as the error does not 
appear in a debug log):
 >>> figure()
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=640.0, height=480.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
2007年11月20日 18:21:32.073 Python[24293] *** _NSAutoreleaseNoPool(): 
Object 0x180822b0 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=654.0, height=494.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
 <matplotlib.figure.Figure instance at 0x18618e40>
 >>>
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>
> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
> > Trailing whitespace introduces noise--sometimes a *lot* of noise--into
> > svn changesets. I would very much appreciate it if everyone would try
> > to eliminate trailing whitespace before committing any changes to svn.
> > (And also eliminate hard tabs--I haven't seen many new ones creeping in,
> > but continuing vigilence is appreciated.)
While I'm happy to play along ( I configured my emacs to detect
whitespace) and suspect I may have been a trailing whitespace
contributer, I fear this may be a case where the cure is worse than
the disease. As we all make commits to fix the trailing whitespaces,
since they are now glaringly ugly in my emacs buffer, I fear we will
see significantly more changesets which are whitespace only, than if
we simply configured our editors to ignore them.
JDH

On Nov 20, 2007 9:15 AM, Rob Hetland <he...@ta...> wrote:
>
> On Nov 20, 2007, at 3:12 PM, John Hunter wrote:
> I am using Mac OS X 10.4.11, python 2.5, and svn versions of numpy
> and mpl. I use Tk/Tcl 8.4.7 that (if I remember right) came with the
> OS. I did not use the simple_plot, but I did try the 'g' trick on a
> normal plot, and tried to run the keypress_demo. So, although I
> didn't do _exactly_ what you are doing, it is essentially the same.
Are you on this box now to verify the problem? There was a bug in
keypress_demo, because the demo was using 'g' to turn the grid on and
off and the default key interaction was doing the same, resulting in a
double toggle and no change. I fixed this bug in svn. I looked
through the diffs from r3393 to present and cannot find anything which
explains the difference.
I'm assuming that some of the other key events (eg press 'x' when
panning to constrain the zoom to the x axis) are also failing. And
you have the window focus (click on the subplot) when testing...
JDH

On Nov 20, 2007, at 3:12 PM, John Hunter wrote:
> I am using tkagg with svn and key events are working. Just to make
> sure we are doing exactly the same thing, I am running
> examples/simple_plot.py with -dTkAgg and clicking in the subplot area
> and then pressing 'g' to toggle the grid on and off. Does this not
> work for you. In your earlier post, you mentioned something about
> carbon. Can you give some more details on your exact environment?
I am using Mac OS X 10.4.11, python 2.5, and svn versions of numpy 
and mpl. I use Tk/Tcl 8.4.7 that (if I remember right) came with the 
OS. I did not use the simple_plot, but I did try the 'g' trick on a 
normal plot, and tried to run the keypress_demo. So, although I 
didn't do _exactly_ what you are doing, it is essentially the same.
I am using Rev: 3393 (Last Changed Date: 2007年06月14日 20:29:49 +0200 
(2007年6月14日)) right now, and it works there.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Nov 20, 2007 7:44 AM, Rob Hetland <he...@ta...> wrote:
>
>
> I sent a note a while ago about a key events being broken. I have a
> bit more information, but still no solution:
>
> - Other mouse-based events seem to work just fine
> - Key events broke somewhere between 2007年11月7日 and 2007年11月10日
I am using tkagg with svn and key events are working. Just to make
sure we are doing exactly the same thing, I am running
examples/simple_plot.py with -dTkAgg and clicking in the subplot area
and then pressing 'g' to toggle the grid on and off. Does this not
work for you. In your earlier post, you mentioned something about
carbon. Can you give some more details on your exact environment?
JDH

I sent a note a while ago about a key events being broken. I have a 
bit more information, but still no solution:
 - Other mouse-based events seem to work just fine
 - Key events broke somewhere between 2007年11月7日 and 2007年11月10日
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Seems like a good idea to me. I'm a little surprised we haven't seen 
this case before. Thanks for the patch -- it's committed in SVN r4391.
Cheers,
Mike
Ben North wrote:
> Hi,
> 
> I think there is a bug in the PostScript backend, when trying to draw a
> polygon with zero linewidth. If you have a zero linewidth, the
> generated PostScript is along the lines of
> 
> 173.31 49.274 m
> 305.066 57.999 l
> 173.533 46.684 l
> closepath
> gsave
> fill
> grestore
> 
> whereas if there is a non-zero linewidth, you get
> 
> 173.31 49.274 m
> 305.066 57.999 l
> 173.533 46.684 l
> closepath
> gsave
> fill
> grestore
> stroke
> 
> The problem is that in the zero-linewidth case, the path is not cleared.
> Therefore, next time there is a 'stroke', that part of the path is
> stroked. In theory, this doesn't matter because its linewidth is zero,
> but the PostScript docs say not completely unambiguously that a
> zero-width line is as thin as the device allows. Ghostview, for
> instance, makes this noticeably non-zero-width and the result looks
> wrong. Besides, it seems cleaner to leave the current path in the same
> state (i.e., empty) in both cases. The below patch, against SVN head,
> seems to fix this.
> 
> Ben.
> 
> - - - - 8< - - - -
> 
> --- SVN--backend_ps.py 2007年11月20日 12:08:51.036996600 +0000
> +++ backend_ps.py 2007年11月20日 12:09:00.100300100 +0000
> @@ -947,6 +947,9 @@
> 
> if self.linewidth > 0:
> write("stroke\n")
> + else:
> + write("newpath\n")
> +
> if cliprect:
> write("grestore\n")
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

Hi,
I think there is a bug in the PostScript backend, when trying to draw a
polygon with zero linewidth. If you have a zero linewidth, the
generated PostScript is along the lines of
 173.31 49.274 m
 305.066 57.999 l
 173.533 46.684 l
 closepath
 gsave
 fill
 grestore
whereas if there is a non-zero linewidth, you get
 173.31 49.274 m
 305.066 57.999 l
 173.533 46.684 l
 closepath
 gsave
 fill
 grestore
 stroke
The problem is that in the zero-linewidth case, the path is not cleared.
Therefore, next time there is a 'stroke', that part of the path is
stroked. In theory, this doesn't matter because its linewidth is zero,
but the PostScript docs say not completely unambiguously that a
zero-width line is as thin as the device allows. Ghostview, for
instance, makes this noticeably non-zero-width and the result looks
wrong. Besides, it seems cleaner to leave the current path in the same
state (i.e., empty) in both cases. The below patch, against SVN head,
seems to fix this.
Ben.
- - - - 8< - - - -
--- SVN--backend_ps.py 2007年11月20日 12:08:51.036996600 +0000
+++ backend_ps.py 2007年11月20日 12:09:00.100300100 +0000
@@ -947,6 +947,9 @@
 if self.linewidth > 0:
 write("stroke\n")
+ else:
+ write("newpath\n")
+
 if cliprect:
 write("grestore\n")

Christopher Barker wrote:
> Jeff Whitaker wrote:
> 
>> 1) an external dependency on the GEOS lib (which is LGPL).
>> 
>
> Would it be any better to depend on an existing python binding GEOS? 
> Here's one option:
>
> http://trac.gispython.org/projects/PCL/wiki/Shapely
>
> -Chris
>
>
> 
Chris: I prototyped the code changes with Shapely (which uses ctypes), 
then coded my own pyrex replacement, both to get more speed and to avoid 
depending on ctypes too.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Christopher Barker wrote:
> 
> Jeff Whitaker wrote:
>> 1) an external dependency on the GEOS lib (which is LGPL).
> 
> Would it be any better to depend on an existing python binding GEOS? 
> Here's one option:
> 
> http://trac.gispython.org/projects/PCL/wiki/Shapely
That is what Jeff started with, but it uses ctypes, and adds complexity 
to the licensing and the installation. Therefore he wrote his own pyrex 
binding to the C API of GEOS, which avoids all that and works fine for 
basemap purposes.
Eric
> 
> -Chris
> 
> 

Jeff Whitaker wrote:
> 1) an external dependency on the GEOS lib (which is LGPL).
Would it be any better to depend on an existing python binding GEOS? 
Here's one option:
http://trac.gispython.org/projects/PCL/wiki/Shapely
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Michael Droettboom wrote:
> I think I'm a little confused by the question. From the Python
> perspective, everything in the Agg backend takes floats. Agg
> actually has color types for both floating point and 8-bit-per-plane
> colors, though obviously it's converted to 8-bit-per-plane
> eventually. But, of course, that is done on the fly without much
> memory copying, so I'm quite surprised that the speed up is
> significant... Where exactly is this conversion happening, and how
> are you now avoiding it? (Is this in code that is not checked in,
> perhaps?)
I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. 
 Both work directly with agg::rgba8, and can benefit from doing a color 
table lookup directly in 8-bit space instead of using floats and then 
converting.
Eric
> 
> As for the other backends, it's a mixed bag. PDF, PS and Cairo want
> floats, SVG wants ints. Personally, I just *like* floats better, as
> it feels more future proof, even though most people aren't using the
> extra color resolution now. (Of course, if your plot relies on
> high-resolution color, you probably need to rethink your plot
> anyway... ;)
> 
> Cheers, Mike

Michael Droettboom wrote:
> 
> Improved consistency is a good thing. And ANSI is a sane choice
> (even though my muscle memory knows K&R, I'm willing to fight against
> that for the betterment of the whole... just don't be surprised if I
> screw some things up initially ;).
> 
> I do have one concern, however. It is very useful for me to be able
> to cross-compare the branch to the trunk, and I wouldn't want there
> to be so many irrelevant differences that that became more difficult.
> It may be that if astyle was run on both the branch and the trunk
> that things would still be okay, but I think it's worth checking
> before committing, just to be sure. We would still have problems
> diffing into the past on either tree, however. That is perhaps an
> argument for waiting and only doing this on the branch (once it
> becomes the trunk).
This is exactly what I was concerned with, also. We can wait. Why 
don't you do it (or give me the all-clear) whenever it seems helpful and 
appropriate. You can choose K&R if you prefer; I have always used ansi 
because it makes the bracket matching clearest to me, but I recognize 
that K&R has an advantage in being more compact. Either is OK.
> 
> Also, I would suggest that we not reformat any code that was brought
> in reasonably clean from other sources (Agg, CXX, ttconv). It is
> useful to diff those files against new versions as they are released.
> 
Agreed, absolutely.
Eric

Improved consistency is a good thing. And ANSI is a sane choice (even though my muscle memory knows K&R, I'm willing to fight against that for the betterment of the whole... just don't be surprised if I screw some things up initially ;).
I do have one concern, however. It is very useful for me to be able to cross-compare the branch to the trunk, and I wouldn't want there to be so many irrelevant differences that that became more difficult. It may be that if astyle was run on both the branch and the trunk that things would still be okay, but I think it's worth checking before committing, just to be sure. We would still have problems diffing into the past on either tree, however. That is perhaps an argument for waiting and only doing this on the branch (once it becomes the trunk).
Also, I would suggest that we not reformat any code that was brought in reasonably clean from other sources (Agg, CXX, ttconv). It is useful to diff those files against new versions as they are released.
Cheers,
Mike

I think I'm a little confused by the question. From the Python perspective, everything in the Agg backend takes floats. Agg actually has color types for both floating point and 8-bit-per-plane colors, though obviously it's converted to 8-bit-per-plane eventually. But, of course, that is done on the fly without much memory copying, so I'm quite surprised that the speed up is significant... Where exactly is this conversion happening, and how are you now avoiding it? (Is this in code that is not checked in, perhaps?)
As for the other backends, it's a mixed bag. PDF, PS and Cairo want floats, SVG wants ints. Personally, I just *like* floats better, as it feels more future proof, even though most people aren't using the extra color resolution now. (Of course, if your plot relies on high-resolution color, you probably need to rethink your plot anyway... ;)
Cheers,
Mike

On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
> Trailing whitespace introduces noise--sometimes a *lot* of noise--into
> svn changesets. I would very much appreciate it if everyone would try
> to eliminate trailing whitespace before committing any changes to svn.
> (And also eliminate hard tabs--I haven't seen many new ones creeping in,
> but continuing vigilence is appreciated.)
Hey Eric,
You probably already know about reindent.py; but since I would rather
not assume and run the risk that you aren't familiar with it, here it
is: http://svn.python.org/view/python/trunk/Tools/scripts/reindent.py?rev=55804&view=markup
It is part of the Python developer's tools and cleans up trailing
whitespace as well as fixing tabs. Ideally everyone should be mindful
as you request, but this is a useful script to occasionally run
anyway.
Thanks for all the great work,
--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/

Would anyone be displeased if I were to reformat all the extension code 
in ansi style? See http://astyle.sourceforge.net/astyle.html. 
Personally, I find the present hodge-podge of styles, and the 
usually-but-not-always 2-space indentation, hard to read and work with; 
I am much more comfortable with the ansi style.
Eric

Mike (and others interested in speed),
I have committed an experimental Axes method temporarily called 
"pcolorfast" that uses one of three methods for rendering a pcolor-type 
plot: an image, a nonuniform image (new implementation in 
_backend_agg.cpp), and a quadmesh. Based on the calling signature and 
the characteristics of the input grid it selects the fastest method. 
The image and nonuniform image are very fast; quadmesh, which is used 
only if the grid is not obviously rectilinear, is much slower, but still 
enormously faster that plain pcolor if the grid is large.
A peculiarity of the method is that what it returns depends on which 
method it picks. It always returns a ScalarMappable, though, so I think 
the other differences are acceptable.
Another peculiarity is that when image-type rendering is used, writing a 
ps file is still fast and efficient, and the file has a reasonable size; 
with quadmesh rendering, a ps file is written based on a polygon 
collection, so it can easily become huge and horribly slow to write. It 
would be better if we could change the default file writing to use an 
image method; then all three methods would perform more similarly on all 
backends. This could involve moving quadmesh from collections to image, 
and changing quadmesh so that it actually returns an image-like entity. 
 This is probably getting beyond my abilities, though.
Long-term, I suspect we will want to keep two pcolor-like methods: the 
original, which does everything with a patch collection, and can draw 
edges; and a modification of pcolorfast (maybe renamed pcolorimage) that 
does everything in an image-oriented mode, and does not draw lines. 
Pcolorfast is for dense grids, and lines simply are not useful with 
dense grids. (Yes, if there are strong requests from users the 
line-drawing could be added back to pcolorfast.)
Eric

Mike (and others),
The standard rgba format in mpl has been a sequence of 4 doubles, but 
these need to be converted to uint8 before they can be used by Agg, at 
least. Therefore I added the ability for ScalarMappable.to_rgba to 
generate uint8 initially, avoiding the extra translation. (This can 
result in a substantial speedup.) I haven't looked into the other 
backends, but I am wondering whether, at least in the transform branch, 
it might make sense to do this more uniformly--that is, go straight to 
uint8. Or are you already doing this, Mike? Does one ever need more 
than 8-bits per channel of color resolution? Are all the backends in 
fact having to do this conversion from 4 doubles to 4 uint8 anyway?
Eric

All,
Trailing whitespace introduces noise--sometimes a *lot* of noise--into 
svn changesets. I would very much appreciate it if everyone would try 
to eliminate trailing whitespace before committing any changes to svn. 
(And also eliminate hard tabs--I haven't seen many new ones creeping in, 
but continuing vigilence is appreciated.)
Thank you.
Eric

On Nov 16, 2007, at 5:14 PM, Rob Hetland wrote:
Darren Dale fixed the first of my three bugs, despite some 
misinformation from me... Thanks, Darren.
> Second, I get this error:
>
> 2007年11月16日 16:53:25.881 Python[6935] *** _NSAutoreleaseNoPool():
> Object 0x18081c10 of class NSCarbonWindowContentView autoreleased
> with no pool in place - just leaking
>
> when plotting text to the screen. I am using mathtext with the Arev
> Sans fonts.
A clarification. I used debug-annoying to find out that it is 
probably not the fonts that cause this error. And I also get it when 
using Qt4. An excerpt of the output is below
>
> Third, keypress events seem to be broken.
I wasn't able to make any progress finding out the cause of this 
problem, unfortunately. Debug gives no information when a key is 
pressed, so apparently the key presses don't make it too far into the 
system..
-Rob
 >>> plot(random.rand(10))
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=640.0, height=480.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
2007年11月17日 18:23:45.474 Python[9859] *** _NSAutoreleaseNoPool(): 
Object 0x18081b80 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=654.0, height=494.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
FigureCanvasAgg.draw
[...more font stuff...]
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331