matplotlib-devel Mailing List for matplotlib

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/