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 [EMAIL PROTECTED] office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu ------------------------------------------------------------------------- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
