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
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
darren.dale@...143...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu