matplotlib-devel Mailing List for matplotlib

On Monday 18 August 2008 09:33:47 Pierre Raybaut wrote:
> Hi Darren,
>
> 2008年8月18日 Darren Dale <dsd...@gm...>:
> >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg'
> >> by '.png' for all the icons to be displayed correctly on the navigation
> >> toolbar (only one was already loaded in the right file format).
> >
> > Could this be a problem with your installation of Qt4? I have been using
> > the
>
> I really don't know, I'll have to check this. I really thought it was
> a bug because the icons aren't all in the same format as if they were
> partially replaced from svg to png for example, so I didn't think it
> could come from my installation. But I'll check my installation.
>
> > svg icons for a while now, without any issues. In what way are they
> > displayed incorrectly?
>
> They are not displayed at all.
>
> > Did you compile qt4 without svg support?
>
> I use the official PyQt binaries, so yes, I guess.
I forgot to mention, the svg icons display fine for me with windows xp, 
matplotlib-0.98.

On Monday 18 August 2008 16:17:03 Pierre Raybaut wrote:
> Darren Dale a écrit :
> >> If you need something to prove that this has nothing to do with my
> >> machine or my software, I can tell you that there is exactly the same
> >> bug on a virtual machine, after a clean Windows XP install, and using
> >> only the official Python MSI installer and the official PyQt installer
> >> (and the latest matplotlib release of course). I also saw the same bug
> >> on three other machines, but the real proof is the VM.
> >
> > I'm not familiar with virtual machines, so I guess I dont understand what
> > that proves. I'm looking for something that indicates this is an issue
> > with matplotlib and not Qt. You found a problem once you upgraded from
> > 4.3.3, but I have not seen a similar problem. I'll try running your test
> > script on a
>
> I've just received another proof (I know that it does not solve the
> problem, but I'm feeling less lonely!): a canadian Python/Qt user
> experienced exactly the same bug (and he did the test on three different
> machines, two with XP and one with Vista).
>
> > windows machine tonight, but in the meantime, perhaps you could try to
> > determine if there is a step in
> > backend_qt4agg.FigureCanvasQTAgg.paintEvent (or somewhere else) that is
> > the source of the bottleneck.
>
> What do you mean exactly?
Nevermind. It turns out its not exactly poor performance, but for some reason 
the gui events were not getting processed as frequently on windows. Maybe Qt 
changed something in an attempt to optimize performance.
I applied a patch in svn 6043, but its a really simple fix. At the end of 
backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line:
 QtGui.qApp.processEvents()
It seemed to improve things on my windows laptop, but let me know if it fixes 
the problem for you.
Darren

Jae-Joon Lee wrote:
> Hi all,
> 
> With the current svn, It fails with the following Exception if I try
> to draw markers (I'm using GtkAgg backends and I presume this only
> happens with Agg backends). Can others confirm this?
> 
> 745 renderer.draw_markers(
> 746 gc, Path.unit_circle(), transform, path, path_trans,
> --> 747 rgbFace)
> 748
> 749
> 
> ValueError: Codes array is wrong length
> 
> 
> And this seems to be due to the error checking code in
> "src/agg_py_path_iterator.h" recently introduced by Michael (r6033).
> At line 42,
> 
> if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 1))
> throw Py::ValueError("Codes array is wrong length");
> 
> I guess the second argument of the PyArray_DIM should be 0 in both cases.
> 
> if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 0))
> throw Py::ValueError("Codes array is wrong length");
> 
> 
> Above simple change worked fine for me.
Thank you, I committed the fix.
Eric
> 
> Regards,
> 
> -JJ
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Darren Dale a écrit :
>> If you need something to prove that this has nothing to do with my
>> machine or my software, I can tell you that there is exactly the same
>> bug on a virtual machine, after a clean Windows XP install, and using
>> only the official Python MSI installer and the official PyQt installer
>> (and the latest matplotlib release of course). I also saw the same bug
>> on three other machines, but the real proof is the VM.
>> 
>
> I'm not familiar with virtual machines, so I guess I dont understand what that 
> proves. I'm looking for something that indicates this is an issue with 
> matplotlib and not Qt. You found a problem once you upgraded from 4.3.3, but 
> I have not seen a similar problem. I'll try running your test script on a 
> 
I've just received another proof (I know that it does not solve the 
problem, but I'm feeling less lonely!): a canadian Python/Qt user 
experienced exactly the same bug (and he did the test on three different 
machines, two with XP and one with Vista).
> windows machine tonight, but in the meantime, perhaps you could try to 
> determine if there is a step in backend_qt4agg.FigureCanvasQTAgg.paintEvent 
> (or somewhere else) that is the source of the bottleneck.
> 
What do you mean exactly?
Pierre

Hi all,
With the current svn, It fails with the following Exception if I try
to draw markers (I'm using GtkAgg backends and I presume this only
happens with Agg backends). Can others confirm this?
 745 renderer.draw_markers(
 746 gc, Path.unit_circle(), transform, path, path_trans,
--> 747 rgbFace)
 748
 749
ValueError: Codes array is wrong length
And this seems to be due to the error checking code in
"src/agg_py_path_iterator.h" recently introduced by Michael (r6033).
At line 42,
 if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 1))
 throw Py::ValueError("Codes array is wrong length");
I guess the second argument of the PyArray_DIM should be 0 in both cases.
 if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 0))
 throw Py::ValueError("Codes array is wrong length");
Above simple change worked fine for me.
Regards,
-JJ

On Monday 18 August 2008 09:33:47 am Pierre Raybaut wrote:
> Hi Darren,
>
> 2008年8月18日 Darren Dale <dsd...@gm...>:
> >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg'
> >> by '.png' for all the icons to be displayed correctly on the navigation
> >> toolbar (only one was already loaded in the right file format).
> >
> > Could this be a problem with your installation of Qt4? I have been using
> > the
>
> I really don't know, I'll have to check this. I really thought it was
> a bug because the icons aren't all in the same format as if they were
> partially replaced from svg to png for example, so I didn't think it
> could come from my installation. But I'll check my installation.
As of version 4.2, Qt supports svg icons. I'll check this on a windows 
computer tonight, if there is an issue on windows, I guess we'll have to go 
back to pngs.
> > svg icons for a while now, without any issues. In what way are they
> > displayed incorrectly?
>
> They are not displayed at all.
>
> > Did you compile qt4 without svg support?
>
> I use the official PyQt binaries, so yes, I guess.
>
> >> (2) I still experience slow performance of pan/zoom feature with the
> >> latest PyQt release (the last release for which I had no problem is the
> >> 4.3.3 release). You'll find attached a simple test script: with PyQt
> >> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in
> >> fact, zooming and panning are happening at the right speed but after a
> >> short delay from the mouse click)
> >
> > I think I need a more quantitative test script that proves this is an
> > issue with mpl before I can be of help. On my machine, panning and
> > zooming is just as fast with your test script as it is with a simple test
> > plot in pylab using either the qt4agg or gtkagg backends. I have qt-4.4.1
> > and PyQt4-4.4.2 installed. Is there anyway you can profile the poor
> > performance you are seeing?
>
> Is your machine under Windows?
No.
> If you need something to prove that this has nothing to do with my
> machine or my software, I can tell you that there is exactly the same
> bug on a virtual machine, after a clean Windows XP install, and using
> only the official Python MSI installer and the official PyQt installer
> (and the latest matplotlib release of course). I also saw the same bug
> on three other machines, but the real proof is the VM.
I'm not familiar with virtual machines, so I guess I dont understand what that 
proves. I'm looking for something that indicates this is an issue with 
matplotlib and not Qt. You found a problem once you upgraded from 4.3.3, but 
I have not seen a similar problem. I'll try running your test script on a 
windows machine tonight, but in the meantime, perhaps you could try to 
determine if there is a step in backend_qt4agg.FigureCanvasQTAgg.paintEvent 
(or somewhere else) that is the source of the bottleneck.
> So I will take a look again at the 'backend_qt4.py' source code to see
> if there is a way to profile this poor performance.
Thanks, that would be helpful.
Darren

Hi Darren,
2008年8月18日 Darren Dale <dsd...@gm...>:
>> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg'
>> by '.png' for all the icons to be displayed correctly on the navigation
>> toolbar (only one was already loaded in the right file format).
>
> Could this be a problem with your installation of Qt4? I have been using the
I really don't know, I'll have to check this. I really thought it was
a bug because the icons aren't all in the same format as if they were
partially replaced from svg to png for example, so I didn't think it
could come from my installation. But I'll check my installation.
> svg icons for a while now, without any issues. In what way are they displayed
> incorrectly?
They are not displayed at all.
> Did you compile qt4 without svg support?
I use the official PyQt binaries, so yes, I guess.
>
>> (2) I still experience slow performance of pan/zoom feature with the
>> latest PyQt release (the last release for which I had no problem is the
>> 4.3.3 release). You'll find attached a simple test script: with PyQt
>> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in
>> fact, zooming and panning are happening at the right speed but after a
>> short delay from the mouse click)
>
> I think I need a more quantitative test script that proves this is an issue
> with mpl before I can be of help. On my machine, panning and zooming is just
> as fast with your test script as it is with a simple test plot in pylab using
> either the qt4agg or gtkagg backends. I have qt-4.4.1 and PyQt4-4.4.2
> installed. Is there anyway you can profile the poor performance you are
> seeing?
Is your machine under Windows?
If you need something to prove that this has nothing to do with my
machine or my software, I can tell you that there is exactly the same
bug on a virtual machine, after a clean Windows XP install, and using
only the official Python MSI installer and the official PyQt installer
(and the latest matplotlib release of course). I also saw the same bug
on three other machines, but the real proof is the VM.
So I will take a look again at the 'backend_qt4.py' source code to see
if there is a way to profile this poor performance.
Thanks
Pierre
>
> Darren
>
>

Hi Pierre,
On Saturday 16 August 2008 03:08:49 am Pierre Raybaut wrote:
> Hi all,
>
> I'm posting to report two bugs in 'backend_qt4.py' with the latest PyQt
> release:
> (see eventually the attached test script)
>
> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg'
> by '.png' for all the icons to be displayed correctly on the navigation
> toolbar (only one was already loaded in the right file format).
Could this be a problem with your installation of Qt4? I have been using the 
svg icons for a while now, without any issues. In what way are they displayed 
incorrectly? Did you compile qt4 without svg support?
> (2) I still experience slow performance of pan/zoom feature with the
> latest PyQt release (the last release for which I had no problem is the
> 4.3.3 release). You'll find attached a simple test script: with PyQt
> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in
> fact, zooming and panning are happening at the right speed but after a
> short delay from the mouse click)
I think I need a more quantitative test script that proves this is an issue 
with mpl before I can be of help. On my machine, panning and zooming is just 
as fast with your test script as it is with a simple test plot in pylab using 
either the qt4agg or gtkagg backends. I have qt-4.4.1 and PyQt4-4.4.2 
installed. Is there anyway you can profile the poor performance you are 
seeing?
Darren

Thanks a lot for reviewing my patch!
I have corrected most of the problems (I think ;-) )
I indeed introduced memory leak, I think it is fixed now, I have also
reorganized the code to avoid duplication of the cleanup code. I used an
helper function instead of the goto, because this cleanup is needed for
normal exit too, so the helper function can come in handy for that.
std::vector would have been nice, but I tried to respect the original
coding style, maybe this could be changed but I guess the original
author should have something to say about it....
Only thing I did not change is the allocation of acols/arows even when
they are not used. It is not difficult to do, but the code will be a
little more complex and I think that the extra memory used is not
significant: The memory for those mapping structure is doubled (1 float
and 1 int vector of size N, instead of a single int vector of size N), 
but those mapping structures are an order of magnitude smaller than the
image buffer of size N*N of 4 char anyway...
If one agree that this is to be saved at the (slight) expense of code
conciseness/simplicity, I can add this optimisation...
Thanks for pointing the error at the left/bottom pixel lines, it is
corrected now :-)
And I set interpolation to NEAREST by default, so that the behavior of
NonUniformImage remains the same as before if the user do not specify
otherwise (I forgot to do it in the first patch)...
I include the new patch,
Best regards,
Greg.
On Fri, 2008年08月15日 at 15:45 -0400, Michael Droettboom wrote:
> Thanks for all the work you put into this patch.
> 
> As you say, it would be nice to have a generic framework for this so 
> that new types of interpolation could be easily added and to be able to 
> support arbitrary (non-axis-aligned) quadmeshes as well. But that's 
> even more work -- if we keep waiting for everything we want, we'll never 
> get it... ;) I agree that Agg probably won't be much help with that. 
> 
> There are a couple of comments with the patch as it stands -->
> 
> There seems to be a gap extrapolating over the left and bottom edge (see 
> attached screenshot from pcolor_nonuniform.py).
> 
> Memory management looks problematic, some of which I think you inherited 
> from earlier code. For example, arows and acols are never freed. 
> Personally, I think these temporary buffers should be std::vector's so 
> they'll be free'd automatically when scope is left. It might also be 
> nice to move all of the Py_XDECREF's that happen when exceptions are 
> thrown to either a master try/catch block or an "exit" goto label at the 
> bottom. The amount of duplication and care required to ensure 
> everything will be freed by all of the different exit paths is a little 
> cumbersome.
> 
> Also, acols and arows are only used in BILINEAR interpolation, but they 
> are allocated always.
> 
> Once these issues are addressed, it would be great to have someone who 
> *uses* the nonuniform pcolor functionality (Eric Firing?) have a look at 
> this patch for any regressions etc.. Assuming none, I'll be happy to 
> commit it (but I won't be around for a week or so).
> 
> Cheers,
> Mike
> 
> Grégory Lielens wrote:
> > Hi all,
> >
> > here is a patch which implement bilinear interpolation on irregular grid
> > ( i.e. it allows NonUniformImage
> > to accept both 'nearest' and 'bilinear' interpoaltion, instead of only
> > 'nearest'.)
> >
> > It is not perfect, given the current architecture of the image module I
> > think there is not simple way
> > to specify other interpolations (except for 'nearest', all
> > interpolations are implemented at the AGG level, not in
> > matplotlib itself).
> > For the same reason, it is not possible to interpolate before colormap
> > lookup instead of after (and this 
> > is usually where the biggest effect is, when dealing with coarse grid).
> > However, I think it is already quite useful and the best one ca do
> > without a -very- extensive rewrite
> > of the matrix map modules....
> >
> > BTW, I think it also corrects a small bug in the 'nearest'
> > interpolation: the last intervals was ignored
> > in the CVS version, now it is taken into account.
> >
> > BOTH nearest and bilinear interpolation do the same for values oustside
> > the data grid: they just use boundary values (constant extrapolation).
> > I avoided linear extrapolation for 'bilinear', as extrapolation is
> > usually dangerous or meaningless (we can go outside the colormap very
> > fast)...
> >
> > I have included a small example showing how both interpolation works....
> >
> > Any remarks, could this be added before the next release? ;-)
> >
> >
> > Greg.
> >
> >
> >
> >
> >
> > On Mon, 2008年08月11日 at 16:50 +0200, Grégory Lielens wrote:
> > 
> >> On Fri, 2008年08月08日 at 16:05 +0200, Grégory Lielens wrote:
> >> 
> >>> Hello everybody,
> >>>
> >>> I have sent this message to the user group, but thinking of it, it may be more
> >>> relevant to the development mailing list...so here it is again.
> >>>
> >>>
> >>>
> >>> We are looking for the best way to plot a waterfall diagram in
> >>> Matplotlib. The 2 functions which could be used 
> >>> to do that are (as far as I have found) imshow and pcolormesh. Here is a
> >>> small script that use both to compare the output:
> >>>
> >>> -----------------
> >>>
> >>> from pylab import *
> >>>
> >>>
> >>> delta = 0.2
> >>> x = arange(-3.0, 3.0, delta)
> >>> y = arange(-2.0, 2.0, delta)
> >>> X, Y = meshgrid(x, y)
> >>> Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
> >>> Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
> >>> # difference of Gaussians
> >>> Z = 10.0 * (Z2 - Z1)
> >>> figure(1)
> >>> im = imshow(Z,extent=(-3,3,-2,2))
> >>> CS = contour(X, -Y, Z, 6,
> >>> colors='k', # negative contours will be dashed by default
> >>> )
> >>> clabel(CS, fontsize=9, inline=1)
> >>> title('Using imshow')
> >>> figure(2)
> >>> im = pcolormesh(X,-Y,Z)
> >>> CS = contour(X, -Y, Z, 6,
> >>> colors='k', # negative contours will be dashed by default
> >>> )
> >>> clabel(CS, fontsize=9, inline=1)
> >>> title('Using pcolormesh')
> >>> show()
> >>>
> >>> ---------------------
> >>>
> >>>
> >>> The problem is that we need some of the flexibility of pcolormesh (which
> >>> is able to map the matrix of value on any deformed mesh), while
> >>> we would like to use the interpolations available in imshow (which
> >>> explain why the imshow version is much "smoother" than the pcolormesh
> >>> one).
> >>>
> >>> In fact, what would be needed is not the full flexibility of pcolormesh
> >>> (which can map the grid to any kind of shape), we "only" have to deal
> >>> with rectangular grids where x- and y- graduations are irregularly spaced.
> >>>
> >>> Is there a drawing function in Matplotlib which would be able to work
> >>> with such a rectangular non-uniform grid?
> >>> And if not (and a quick look at the example and the code make me think 
> >>> that indeed the capability is currently not present),
> >>> what about an extension of imshow which would work as this:
> >>> 
> >>> im = imshow(Z,x_gridpos=x, y_gridpos=y) #specify the
> >>> position of the grid's nodes, instead of giving the extend and assuming
> >>> uniform spacing.
> >>>
> >>> Longer term, would a pcolormesh accepting interpolation be possible? The
> >>> current behavior, averaging the color of the grids node to get a uniform
> >>> cell color, 
> >>> is quite rough except for a large number of cells...And even then, it
> >>> soon shows when you zoom in...
> >>>
> >>> The best would be to allow the same interpolations as in imshow (or a
> >>> subset of it), and also allows to use interpolation before colormap
> >>> lookup (or after), 
> >>> like in Matlab. Indeed, Matlab allows to finely tune interpolation by
> >>> specifying Gouraud (interpolation after color
> >>> lookup)/Phong(interpolation before color lookup, i.e. for each pixel).
> >>> Phong is usually much better but also more CPU intensive. Phong is
> >>> especially when using discrete colormap, producing banded colors
> >>> equivalent to countour lines, while Gouraud does not work in those
> >>> cases.
> >>>
> >>> Of course, the performance will be impacted by some of those
> >>> interpolation options, which would degrade performance in animations for
> >>> example.... but I think that having the different options available
> >>> would be very useful, it allows to have the highest map quality, or have
> >>> a "quick and dirty" map depending on situation (grid spacing, type of
> >>> map, animation or not, ...).
> >>>
> >>> Best regards,
> >>>
> >>> Greg.
> >>> 
> >> I have found a method which implement the proposed extension to imshow:
> >> NonUniformImage...
> >>
> >> However, this image instance support only nearest neighbor
> >> interpolation. Trying to set the interpolation (using the
> >> set_interpolation method)
> >> to something akin imshow throw a "NotImplementedError: Only nearest
> >> neighbor supported" exception....
> >>
> >> So basically I am still stuck, it seems that currently there is no way
> >> in matplotlib to plot interpolated
> >> colormap on irregular rectangular grid, and even less on arbitrarily
> >> mapped grid...
> >>
> >> Is there any plans to add support for more interpolation in
> >> NonUniformImage in the future? Or maybe there is another 
> >> drawing function that I did not find yet, with this ability?
> >>
> >>
> >> Best regards,
> >>
> >> Greg.
> >>
> >>
> >>
> >> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> 
> >> ------------------------------------------------------------------------
> >>
> >> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel