matplotlib-devel Mailing List for matplotlib (Page 3)

I discovered another blitting bug in backend_qt4agg.py. Qt expects a pixmap 
stringBuffer formatted in ARGB, but mpl formats in RGBA. The qt4 backend 
usually uses the _renderer.tostring_bgra method to return a properly 
formatted buffer:
if QtCore.QSysInfo.ByteOrder == QtCore.QSysInfo.LittleEndian:
 stringBuffer = self.renderer._renderer.tostring_bgra()
else:
 stringBuffer = self.renderer._renderer.tostring_argb()
The problem I am seeing is when we are blitting, and the tostring_bgra is not 
available. The blitting code in backend_qt4agg.py, starting around line 112, 
gets a buffer from a region copied from a bbox:
reg = self.copy_from_bbox(bbox)
stringBuffer = reg.to_string()
qImage = QtGui.QImage(stringBuffer, w, h, QtGui.QImage.Format_ARGB32)
reg does not have a method to swap the byte order, and Qt does not have a 
Format_RGBA32. Could anyone suggest how to swap the byte order?
Thanks,
Darren

Hi,
the doc-string of the axes scatter method is buggy. Somehow the 
svn-conflict messages got committed to the repository:
I mean this
<<<<<<< .working
[...]
=======
[...]
 >>>>>>> .merge-right.r4987
... stuff)
Manuel

Thanks. This has been committed in SVN r5000.
Cheers,
Mike
Michael Fitzgerald wrote:
>
> Hi all,
>
> I encountered problems with the Arrow patch, which broke sometime 
> recently. I'm attaching a fix (diff against svn r4999).
>
> Best,
> Mike
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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 all,
I am trying to place small images (say 128x128) at specific (x,y)
positions on the plotting canvas. I'm sure it is possible, but I
don't know what the magic incantation is. I don't want anyone to
spend time on figuring it out, but if you do know the answer, please
let me know.
Thanks,
Stéfan

Hi Gaël,
I mostly work in an interactive shell (ipython), and if I simply call
a blocking function (like raw_input)
from the prompt, it also blocks the event loop of the matplotlib gui backend
(it happens for GtkAgg, but not for TKAgg. I'm not sure with other
backends, but I thought
TKAgg is a special case.)
So I wanted to call a raw_input (or other blocking function) in an
interactive shell
without freezing the figure.
Hmm, maybe I'm missing something and there has been an very easy way to do it.
My understading was that the gui event loop waits (without processing
gui events)
until the commands entered in the prompt finish.
-JJ
On Mon, Mar 10, 2008 at 7:45 PM, Gael Varoquaux
<gae...@no...> wrote:
> On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote:
>
> > I often need to take an input from other sources
> > (I mean, other than matplotlib itself, e.g., raw_input).
> > I don't think running a blocking function, such as a raw_input,
> > without freezing the figure canvas
> > has been easy in matplotlib (especially when you're in an interactive
> > mode).
>
>
> Hum, I am not sure what is the added value to simply spawning a thread
> and running the blocking function in the thread. The reason I say this is
> that ginput is a hack, and a fragile one. The reason behind ginput is
> that we want to block the call threading while not blocking the GUI event
> loop. Can you please detail your usecase, I am afraid I am missing
> something here.
>
> Cheers,
>
> Gaël
>
> PS: And welcome on the matplotlib-devel list.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,
I encountered problems with the Arrow patch, which broke sometime 
recently. I'm attaching a fix (diff against svn r4999).
Best,
Mike

On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote:
> I often need to take an input from other sources
> (I mean, other than matplotlib itself, e.g., raw_input).
> I don't think running a blocking function, such as a raw_input,
> without freezing the figure canvas
> has been easy in matplotlib (especially when you're in an interactive
> mode).
Hum, I am not sure what is the added value to simply spawning a thread
and running the blocking function in the thread. The reason I say this is
that ginput is a hack, and a fragile one. The reason behind ginput is
that we want to block the call threading while not blocking the GUI event
loop. Can you please detail your usecase, I am afraid I am missing
something here.
Cheers,
Gaël
PS: And welcome on the matplotlib-devel list.

On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote:
> I often need to take an input from other sources
> (I mean, other than matplotlib itself, e.g., raw_input).
> I don't think running a blocking function, such as a raw_input,
> without freezing the figure canvas
> has been easy in matplotlib (especially when you're in an interactive mode).
Hum, I am not sure what is the added value to simply spawning a thread
and running the blocking function in the thread. The reason I say this is
that ginput is a hack, and a fragile one. The reason behind ginput is
that we want to block the call threading while not blocking the GUI event
loop. Can you please detail your usecase, I am afraid I am missing
something here.
Cheers,
Gaël

Hi all,
I found the recent ginput function by Gael is really cool.
On the other hand, I often need to take an input from other sources
(I mean, other than matplotlib itself, e.g., raw_input).
I don't think running a blocking function, such as a raw_input,
without freezing the figure canvas
has been easy in matplotlib (especially when you're in an interactive mode).
But with ginput in place now, it seems quite easy.
So, I'm attaching my simple implementation of ginput-like function for
an arbitrary blocking function.
The code is largely based on the current ginput implementation.
You can use it as
>>> from PylabBlockingInput import BlockingInput
>>> readinput = BlockingInput(raw_input)
>>> r = readinput()
The blocking function itself is run in a separate thread while the
main thread updates the
figure with flush_events calls. Here are a few things
 * I only tested this with GtkAgg backend.
 * I must admit that I have very little experience with thread
 programming, and I'm not sure how usable (or safe) this approach
will be in general.
 * Since the blocking function is not attached to any particular
figure, gcf().canvas.flush_events is
 run by default.
I hope this is useful to others
and any comments will be welcomed.
Cheers,
-JJ
ps. I believe this is my first post in matplotlib-devel list. Thanks a
lot to John and others for a great plotting package.

I just saw this today myself. Apparently my password has "expired" 
(first time in years I've seen that happen).
I logged in to the sf.net web interface, it asked for my old and new 
passwords, and then I was able to use the new password with SVN.
Maybe this is a new policy?
Mike
Darren Dale wrote:
> Sourceforge is rejecting my commits, as if my username or password were 
> incorrect. Is anyone else able to commit to svn?
>
> Darren
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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

That sounds fine to me. I just wanted to make sure that I wasn't glossing over 
a bug that could turn up elsewhere.
Thanks,
Darren
On Monday 10 March 2008 08:46:36 am Michael Droettboom wrote:
> No, I didn't see this message, but I think we arrived at the same
> conclusion. I think the solution is just to calculate the width and
> height in the same way in both places (copy_to_bbox and the Qt blitting
> code in Python). We can't change bbox.bounds, since many other parts of
> the code rely on that calculation being in pure floating point. But
> there's only two places (in Qt and Qt4) that rely on the rounding
> behavior of copy_to_bbox, and IMHO, the way it does the rounding is the
> sanest way given that the edges must be integer-aligned.
>
> I've committed these changes in r4995.
>
> Cheers,
> Mike
>
> Darren Dale wrote:
> > Hi Mike,
> >
> > On Monday 10 March 2008 08:24:27 am you wrote:
> >> Sorry, I didn't see this latest e-mail before I replied before. I see
> >> the shearing now that I've adjusted window size. Maybe it could be
> >> related to the fact that width != span? Anyway, I'll investigated
> >> further and get back.
> >
> > Thanks for having a look. But before you dig to deep, did you see my last
> > post to this thread?:
> >
> > -----
> > I think this problem is due to a loss of precision in _backend_agg's
> > copy_from_bbox. That method takes a bbox with double precision as input,
> > and constructs a rect with ints as input:
> >
> > agg::rect_i rect((int)l, height - (int)t, (int)r, height - (int)b);
> >
> > A rendering buffer is created with a width based on that rect. Half of
> > the time, the width of that buffer disagrees with the width reported by
> > the original bbox. For example, I can kludge the bbox width so it agrees
> > with the output of copy_from_bbox:
> >
> > l, b, w, h = bbox.bounds
> > r = int(l+w)
> > w_mod = r-int(l)
> >
> > I can use w_mod instead of w as a workaround for the blitting issue I
> > reported, but I wonder if there might be a better solution?
> > ------
> >
> >> Darren Dale wrote:
> >>> On Friday 07 March 2008 4:58:03 pm Darren Dale wrote:
> >>>> I am having some trouble with the Cursor widget with the qt4agg
> >>>> backend. Here is a short script which works with the gtkagg backend
> >>>> with useblit either true or false:
> >>>>
> >>>> ----------
> >>>> from matplotlib import rcParams
> >>>> rcParams['backend']='gtkagg'
> >>>> from pylab import *
> >>>> from matplotlib.widgets import Cursor
> >>>>
> >>>> t = arange(0.0, 1.0, 0.01)
> >>>> s = sin(2*2*pi*t)
> >>>> ax = subplot(111)
> >>>>
> >>>> cursor = Cursor(ax, useblit=True)
> >>>>
> >>>> ax.plot(t, s, 'o')
> >>>> axis([0,1,-1,1])
> >>>> show()
> >>>> ------------
> >>>>
> >>>> If I use the qt4agg backend, with useblit False, the cursor lines do
> >>>> not render. If useblit is True, the lines render but the pixmap inside
> >>>> the axes is sheared. I've been looking at the backend_qt4agg code, the
> >>>> widgets.Cursor code, and the working animation_blit_qt4 example, but
> >>>> I'm stuck. Does anyone have any ideas?
> >>>
> >>> Here is an additional wrinkle, sometimes the pixmap is sheared, and
> >>> sometimes it is not. The behavior seems to shift back and forth when I
> >>> change the horizontal size of the figure window, bu I don't see a
> >>> pattern emerging that would explain why: 556-559 pixels wide is
> >>> sheared, 560-564 looks ok, 565-567 is sheared, 568 is normal, 569 and
> >>> 570 are sheared, etc. The
> >>> animation_blit_qt4 demo also has the same problem, depending on the
> >>> horizontal size. So confusing.
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

No, I didn't see this message, but I think we arrived at the same 
conclusion. I think the solution is just to calculate the width and 
height in the same way in both places (copy_to_bbox and the Qt blitting 
code in Python). We can't change bbox.bounds, since many other parts of 
the code rely on that calculation being in pure floating point. But 
there's only two places (in Qt and Qt4) that rely on the rounding 
behavior of copy_to_bbox, and IMHO, the way it does the rounding is the 
sanest way given that the edges must be integer-aligned.
I've committed these changes in r4995.
Cheers,
Mike
Darren Dale wrote:
> Hi Mike,
>
> On Monday 10 March 2008 08:24:27 am you wrote:
> 
>> Sorry, I didn't see this latest e-mail before I replied before. I see
>> the shearing now that I've adjusted window size. Maybe it could be
>> related to the fact that width != span? Anyway, I'll investigated
>> further and get back.
>> 
>
> Thanks for having a look. But before you dig to deep, did you see my last post 
> to this thread?:
>
> -----
> I think this problem is due to a loss of precision in _backend_agg's 
> copy_from_bbox. That method takes a bbox with double precision as input, and 
> constructs a rect with ints as input:
>
> agg::rect_i rect((int)l, height - (int)t, (int)r, height - (int)b);
>
> A rendering buffer is created with a width based on that rect. Half of the 
> time, the width of that buffer disagrees with the width reported by the 
> original bbox. For example, I can kludge the bbox width so it agrees with the 
> output of copy_from_bbox:
>
> l, b, w, h = bbox.bounds
> r = int(l+w)
> w_mod = r-int(l)
>
> I can use w_mod instead of w as a workaround for the blitting issue I 
> reported, but I wonder if there might be a better solution?
> ------
>
> 
>> Darren Dale wrote:
>> 
>>> On Friday 07 March 2008 4:58:03 pm Darren Dale wrote:
>>> 
>>>> I am having some trouble with the Cursor widget with the qt4agg backend.
>>>> Here is a short script which works with the gtkagg backend with useblit
>>>> either true or false:
>>>>
>>>> ----------
>>>> from matplotlib import rcParams
>>>> rcParams['backend']='gtkagg'
>>>> from pylab import *
>>>> from matplotlib.widgets import Cursor
>>>>
>>>> t = arange(0.0, 1.0, 0.01)
>>>> s = sin(2*2*pi*t)
>>>> ax = subplot(111)
>>>>
>>>> cursor = Cursor(ax, useblit=True)
>>>>
>>>> ax.plot(t, s, 'o')
>>>> axis([0,1,-1,1])
>>>> show()
>>>> ------------
>>>>
>>>> If I use the qt4agg backend, with useblit False, the cursor lines do not
>>>> render. If useblit is True, the lines render but the pixmap inside the
>>>> axes is sheared. I've been looking at the backend_qt4agg code, the
>>>> widgets.Cursor code, and the working animation_blit_qt4 example, but I'm
>>>> stuck. Does anyone have any ideas?
>>>> 
>>> Here is an additional wrinkle, sometimes the pixmap is sheared, and
>>> sometimes it is not. The behavior seems to shift back and forth when I
>>> change the horizontal size of the figure window, bu I don't see a pattern
>>> emerging that would explain why: 556-559 pixels wide is sheared, 560-564
>>> looks ok, 565-567 is sheared, 568 is normal, 569 and 570 are sheared,
>>> etc. The
>>> animation_blit_qt4 demo also has the same problem, depending on the
>>> horizontal size. So confusing.
>>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sourceforge is rejecting my commits, as if my username or password were 
incorrect. Is anyone else able to commit to svn?
Darren

Sorry, I didn't see this latest e-mail before I replied before. I see 
the shearing now that I've adjusted window size. Maybe it could be 
related to the fact that width != span? Anyway, I'll investigated 
further and get back.
Cheers,
Mike
Darren Dale wrote:
> On Friday 07 March 2008 4:58:03 pm Darren Dale wrote:
> 
>> I am having some trouble with the Cursor widget with the qt4agg backend.
>> Here is a short script which works with the gtkagg backend with useblit
>> either true or false:
>>
>> ----------
>> from matplotlib import rcParams
>> rcParams['backend']='gtkagg'
>> from pylab import *
>> from matplotlib.widgets import Cursor
>>
>> t = arange(0.0, 1.0, 0.01)
>> s = sin(2*2*pi*t)
>> ax = subplot(111)
>>
>> cursor = Cursor(ax, useblit=True)
>>
>> ax.plot(t, s, 'o')
>> axis([0,1,-1,1])
>> show()
>> ------------
>>
>> If I use the qt4agg backend, with useblit False, the cursor lines do not
>> render. If useblit is True, the lines render but the pixmap inside the axes
>> is sheared. I've been looking at the backend_qt4agg code, the
>> widgets.Cursor code, and the working animation_blit_qt4 example, but I'm
>> stuck. Does anyone have any ideas?
>> 
>
> Here is an additional wrinkle, sometimes the pixmap is sheared, and sometimes 
> it is not. The behavior seems to shift back and forth when I change the 
> horizontal size of the figure window, bu I don't see a pattern emerging that 
> would explain why: 556-559 pixels wide is sheared, 560-564 looks ok, 565-567 
> is sheared, 568 is normal, 569 and 570 are sheared, etc. The 
> animation_blit_qt4 demo also has the same problem, depending on the 
> horizontal size. So confusing.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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

With the qt4agg backend, I also get no cursor with "useblit=False", but 
when "useblit=True" it seems to work just fine -- I don't see any 
shearing. By shearing I assume you mean the image is warped like a 
parallelogram? Or do mean tearing, in that it isn't updating fast 
enough? (FWIW, I don't see either).
What versions of Qt do you have? I've got:
 Qt: Qt: 3.3.3, PyQt: 3.17.2
 Qt4: Qt: 4.3.0, PyQt4: 4.2
Cheers,
Mike
Darren Dale wrote:
> I am having some trouble with the Cursor widget with the qt4agg backend. Here 
> is a short script which works with the gtkagg backend with useblit either 
> true or false:
>
> ----------
> from matplotlib import rcParams
> rcParams['backend']='gtkagg'
> from pylab import *
> from matplotlib.widgets import Cursor
>
> t = arange(0.0, 1.0, 0.01)
> s = sin(2*2*pi*t)
> ax = subplot(111)
>
> cursor = Cursor(ax, useblit=True)
>
> ax.plot(t, s, 'o')
> axis([0,1,-1,1])
> show()
> ------------
>
> If I use the qt4agg backend, with useblit False, the cursor lines do not 
> render. If useblit is True, the lines render but the pixmap inside the axes 
> is sheared. I've been looking at the backend_qt4agg code, the widgets.Cursor 
> code, and the working animation_blit_qt4 example, but I'm stuck. Does anyone 
> have any ideas?
>
> Thanks,
> Darren
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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

I've got an MPL widget embedded in a qt application. The user interacts w/
the GUI and causes data to be shown or hidden in the plot. Since the data
can be very large (5-10 lines w/ 40,000 points in each), I've written code
that reads the data and builds Line2D objects. Then I call axes.add_line()
and line.remove() to add and remove them from my plot.
This works fine when the x axis is a floating point axis. If I switch the x
axis to dates, then when I try to re-add some removed lines, I get the error
at the bottom of the email. A script that duplicates this is attached
(though I think you need to have an interactive mode session running to
really see what happens. 
As an example:
1) read data and build 4 Line2D objects
2) user shows lines 1 and 2 
3) user hides lines 1 and 2, shows lines 3 and 4
4) user hides lines 3 and 4, shows lines 1 and 2
These steps work fine w/ floats. But if I tell the xaxis to be date
(axis.xaxis_date()), then step 4 above will give the error:
 File "./error.py", line 62, in <module>
 run( True )
 File "./error.py", line 53, in run
 ax.autoscale_view()
 File
"/group/monte/development/rh8/tools.2007_03_13/lib/python2.5/site-packages/m
atplotlib/axes.py", line 1268, in autoscale_view
 XL = self.xaxis.get_major_locator().autoscale()
 File
"/group/monte/development/rh8/tools.2007_03_13/lib/python2.5/site-packages/m
atplotlib/dates.py", line 568, in autoscale
 dmin, dmax = self.datalim_to_dt()
 File
"/group/monte/development/rh8/tools.2007_03_13/lib/python2.5/site-packages/m
atplotlib/dates.py", line 434, in datalim_to_dt
 return num2date(dmin, self.tz), num2date(dmax, self.tz)
 File
"/group/monte/development/rh8/tools.2007_03_13/lib/python2.5/site-packages/m
atplotlib/dates.py", line 234, in num2date
 if not cbook.iterable(x): return _from_ordinalf(x, tz)
 File
"/group/monte/development/rh8/tools.2007_03_13/lib/python2.5/site-packages/m
atplotlib/dates.py", line 157, in _from_ordinalf
 dt = datetime.datetime.fromordinal(ix)
ValueError: ordinal must be >= 1
Any help would be greatly appreciated. It almost seems like using date mode
is somehow changing the Line2D object. I tried not clearing the figure and
just removing the lines, but that causes other problems (the plot won't
autoscale in step 4 and I also need to toggle other items on and off -
legends and things).
Thanks,
Ted

On Saturday 08 March 2008 11:36:45 am Darren Dale wrote:
> On Friday 07 March 2008 4:58:03 pm Darren Dale wrote:
> > I am having some trouble with the Cursor widget with the qt4agg backend.
> > Here is a short script which works with the gtkagg backend with useblit
> > either true or false:
> >
> > ----------
> > from matplotlib import rcParams
> > rcParams['backend']='gtkagg'
> > from pylab import *
> > from matplotlib.widgets import Cursor
> >
> > t = arange(0.0, 1.0, 0.01)
> > s = sin(2*2*pi*t)
> > ax = subplot(111)
> >
> > cursor = Cursor(ax, useblit=True)
> >
> > ax.plot(t, s, 'o')
> > axis([0,1,-1,1])
> > show()
> > ------------
> >
> > If I use the qt4agg backend, with useblit False, the cursor lines do not
> > render. If useblit is True, the lines render but the pixmap inside the
> > axes is sheared. I've been looking at the backend_qt4agg code, the
> > widgets.Cursor code, and the working animation_blit_qt4 example, but I'm
> > stuck. Does anyone have any ideas?
>
> Here is an additional wrinkle, sometimes the pixmap is sheared, and
> sometimes it is not. The behavior seems to shift back and forth when I
> change the horizontal size of the figure window, bu I don't see a pattern
> emerging that would explain why: 556-559 pixels wide is sheared, 560-564
> looks ok, 565-567 is sheared, 568 is normal, 569 and 570 are sheared, etc.
> The
> animation_blit_qt4 demo also has the same problem, depending on the
> horizontal size. So confusing.
I think this problem is due to a loss of precision in _backend_agg's 
copy_from_bbox. That method takes a bbox with double precision as input, and 
constructs a rect with ints as input:
 agg::rect_i rect((int)l, height - (int)t, (int)r, height - (int)b);
A rendering buffer is created with a width based on that rect. Half of the 
time, the width of that buffer disagrees with the width reported by the 
original bbox. For example, I can kludge the bbox width so it agrees with the 
output of copy_from_bbox:
 l, b, w, h = bbox.bounds
 r = int(l+w)
 w_mod = r-int(l)
I can use w_mod instead of w as a workaround for the blitting issue I 
reported, but I wonder if there might be a better solution?
Thanks,
Darren

On Friday 07 March 2008 4:58:03 pm Darren Dale wrote:
> I am having some trouble with the Cursor widget with the qt4agg backend.
> Here is a short script which works with the gtkagg backend with useblit
> either true or false:
>
> ----------
> from matplotlib import rcParams
> rcParams['backend']='gtkagg'
> from pylab import *
> from matplotlib.widgets import Cursor
>
> t = arange(0.0, 1.0, 0.01)
> s = sin(2*2*pi*t)
> ax = subplot(111)
>
> cursor = Cursor(ax, useblit=True)
>
> ax.plot(t, s, 'o')
> axis([0,1,-1,1])
> show()
> ------------
>
> If I use the qt4agg backend, with useblit False, the cursor lines do not
> render. If useblit is True, the lines render but the pixmap inside the axes
> is sheared. I've been looking at the backend_qt4agg code, the
> widgets.Cursor code, and the working animation_blit_qt4 example, but I'm
> stuck. Does anyone have any ideas?
Here is an additional wrinkle, sometimes the pixmap is sheared, and sometimes 
it is not. The behavior seems to shift back and forth when I change the 
horizontal size of the figure window, bu I don't see a pattern emerging that 
would explain why: 556-559 pixels wide is sheared, 560-564 looks ok, 565-567 
is sheared, 568 is normal, 569 and 570 are sheared, etc. The 
animation_blit_qt4 demo also has the same problem, depending on the 
horizontal size. So confusing.

I am having some trouble with the Cursor widget with the qt4agg backend. Here 
is a short script which works with the gtkagg backend with useblit either 
true or false:
----------
from matplotlib import rcParams
rcParams['backend']='gtkagg'
from pylab import *
from matplotlib.widgets import Cursor
t = arange(0.0, 1.0, 0.01)
s = sin(2*2*pi*t)
ax = subplot(111)
cursor = Cursor(ax, useblit=True)
ax.plot(t, s, 'o')
axis([0,1,-1,1])
show()
------------
If I use the qt4agg backend, with useblit False, the cursor lines do not 
render. If useblit is True, the lines render but the pixmap inside the axes 
is sheared. I've been looking at the backend_qt4agg code, the widgets.Cursor 
code, and the working animation_blit_qt4 example, but I'm stuck. Does anyone 
have any ideas?
Thanks,
Darren