matplotlib-devel Mailing List for matplotlib

To the fantastic matplotlib developers,
I am having a strange behavior when using zooming.  I have tried it with 
WX, Wxagg, and TKagg, and with Numeric and numpy.  It occurs in multiple 
interpolation types as well.   The best way to see this behavior is to 
use the image_interp.py example.  If you zoom in enough, the image 
starts to fade to white, and then turn completely white.  If you zoom in 
to about where the zoom the axes area spans 0.1 units, it should still 
look fine, but then a span of 0.01 unit will be all white.  If you zoom 
in slowly to where the color is starting to wash out to white, then 
resize the window, you will see more strange whitening behavior (the 
color fluctuates between white and the correct color as you change the 
window size).   This is on a windows machine with Python 2.4.
Another clue.  if I save the white appearing axes to a png, it looks fine.
the way it fades out almost seems like something going wrong with an 
alpha value somewhere...
any thoughts?

thanks,
Tim

Hi Eric,

> I have modified your LogNorm, added it to colors.py, made some changes
> to colorbar.py, and added a stripped-down version of your pcolor_log.py
> to the examples directory.  If you update your mpl from svn, then I
> think you will find that pcolor_log now works the way you expected it to
> originally, with the colorbar automatically supporting the log color scale.

I just upgraded and it works great!

Thanks very much.

JIM
---

Is there any way to get the length (in pixels) of a particular axis?

 

More specifically I am trying to make a clean-looking Formatter object that spaces out the labels so that the text does not write on
top of each other, but in order to do so, I need to know the length of the Axis that the Formatter object is being applied to.  Is
there any easy (or proper) way to do this?

 

While I am on the topic, are there any ways to get the pixel size of a string if it were to be rendered as text?  I know that Qt can
do this, but I wasn't sure if the matplotlib backend system has this implemented to make it generic for all backends.  Right now I
just have a hard-coded parameter for this, but it would be nice to make more automatic.

 

Thanks,

--James Evans

John,

Thanks.  I have deleted it.

Eric

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
> 
>     Eric> Despite the comment, I don't understand the purpose of the
>     Eric> last line in the following excerpt from the Axes.plot()
>     Eric> method:
> 
>     Eric>          lines = [] for line in self._get_lines(*args,
>     Eric> **kwargs): self.add_line(line) lines.append(line) lines =
>     Eric> [line for line in lines] # consume the generator
> 
> That looks like detritus.  If I recall correctly, it used to be
> something like
> 
>          lines = self._get_lines(*args, **kwargs):
>          lines = [line for line in lines] # consume the generator
> 
> _get_lines is a generator and there was some part of the code that was
> having trouble with this so I just converted it to a list and that
> fixed the bug.  Later it appears the code was rewritten to what you
> posted and lines is already a list, so yes, the list comprehension is
> redundant and should be removed.
> 
> JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Despite the comment, I don't understand the purpose of the
    Eric> last line in the following excerpt from the Axes.plot()
    Eric> method:

    Eric>          lines = [] for line in self._get_lines(*args,
    Eric> **kwargs): self.add_line(line) lines.append(line) lines =
    Eric> [line for line in lines] # consume the generator

That looks like detritus.  If I recall correctly, it used to be
something like

         lines = self._get_lines(*args, **kwargs):
         lines = [line for line in lines] # consume the generator

_get_lines is a generator and there was some part of the code that was
having trouble with this so I just converted it to a list and that
fixed the bug.  Later it appears the code was rewritten to what you
posted and lines is already a list, so yes, the list comprehension is
redundant and should be removed.

JDH

Hello James

Essentially the qt event-loop will only be started by matplotlib if
> matplotlib was the one to create the qApp, if not then it is up
> to the creator of the Qt qApp to start the event-loop when they are ready
> for it.  This allows for applications with embedded Qt
> event loops to work with matplotlib.  I have run some test cases in a few
> different python environments (including the vanilla
> python) and all seem to be working.  I have not, however tested this in
> the iPython environment (although I don't think that iPython
> uses Qt, does it?).


Yes, it does. There is a command-line switch to make iPython run the qt
mainloop in a separate thread.

Use "ipython -qthread".

Also, there is "ipython -pylab" that run default GUI toolkit (as defined in
matplotlibrc) mainloop in a thread.

-- 
Regards
Leandro Lameiro

Blog: http://lameiro.wordpress.com

Despite the comment, I don't understand the purpose of the last line in 
the following excerpt from the Axes.plot() method:

         lines = []
         for line in self._get_lines(*args, **kwargs):
             self.add_line(line)
             lines.append(line)
         lines = [line for line in lines] # consume the generator

Would someone enlighten me, please?  Or is that line in fact as useless 
as it appears to me?

Thanks.

Eric