Menu
▾
▴
matplotlib-users
|
From: João L. S. <js...@fc...> - 2010-07-12 22:59:03
Attachments:
plot_moves.py
plot_moves.png
|
Hi, I've finally created a small script that demonstrates a bug that I've been enduring for a long time. I haven't seen it reported before, so I may be doing something wrong. The bug is as follows: Under certain conditions, in an embedded gtk application, when selecting an area with the "Zoom to rectangle" button from the toolbar the whole graph will jump upward temporarily, corrupting the screen and making it hard to select the proper area. The attached example is an extreme version of this (the effect would be smaller for a reasonably sized combo box). Tested on Linux (Debian Squeeze). Regards, João Luís Silva |
|
From: John H. <jd...@gm...> - 2010-07-12 23:15:27
|
On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote: > Hi, > > I've finally created a small script that demonstrates a bug that I've been > enduring for a long time. I haven't seen it reported before, so I may be > doing something wrong. The bug is as follows: Under certain conditions, in > an embedded gtk application, when selecting an area with the "Zoom to > rectangle" button from the toolbar the whole graph will jump upward > temporarily, corrupting the screen and making it hard to select the proper > area. The attached example is an extreme version of this (the effect would > be smaller for a reasonably sized combo box). > > Tested on Linux (Debian Squeeze). You have this line: from widgets import Widgets what is "widgets" ? JDH |
|
From: João L. S. <js...@fc...> - 2010-07-12 23:40:01
|
John Hunter wrote: > On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote: >> Hi, >> >> I've finally created a small script that demonstrates a bug that I've been >> enduring for a long time. I haven't seen it reported before, so I may be >> doing something wrong. The bug is as follows: Under certain conditions, in >> an embedded gtk application, when selecting an area with the "Zoom to >> rectangle" button from the toolbar the whole graph will jump upward >> temporarily, corrupting the screen and making it hard to select the proper >> area. The attached example is an extreme version of this (the effect would >> be smaller for a reasonably sized combo box). >> >> Tested on Linux (Debian Squeeze). > > > You have this line: > > from widgets import Widgets > > what is "widgets" ? > > JDH > Sorry, I forgot to delete it. It's just a small helper class I use to load files from glade. By the way, I just tested the script on Windows (after deleting that line) and it doesn't have the bug (Python 2.5 + mpl 1.0.0) JLS |
|
From: John H. <jd...@gm...> - 2010-07-13 01:05:38
|
On Mon, Jul 12, 2010 at 6:39 PM, João Luís Silva <js...@fc...> wrote: > > > John Hunter wrote: >> >> On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva >> <jsi...@pu...> wrote: >>> >>> Hi, >>> >>> I've finally created a small script that demonstrates a bug that I've >>> been >>> enduring for a long time. I haven't seen it reported before, so I may be >>> doing something wrong. The bug is as follows: Under certain conditions, >>> in >>> an embedded gtk application, when selecting an area with the "Zoom to >>> rectangle" button from the toolbar the whole graph will jump upward >>> temporarily, corrupting the screen and making it hard to select the >>> proper >>> area. The attached example is an extreme version of this (the effect >>> would >>> be smaller for a reasonably sized combo box). >>> >>> Tested on Linux (Debian Squeeze). >> >> >> You have this line: >> >> from widgets import Widgets >> >> what is "widgets" ? >> >> JDH >> > > Sorry, I forgot to delete it. It's just a small helper class I use to load > files from glade. By the way, I just tested the script on Windows (after > deleting that line) and it doesn't have the bug (Python 2.5 + mpl 1.0.0) I also see buggy behavior, but on my ubuntu linux system I see that the whole subplot gets painted black on a mouse press and remains so while the rubber-banding is in effect. It's not strictly black, but it looks like blackish bit noise. I also notice if I don't add the combobox to the vbox, I have no problem. But I don't see that the "plot moves".... It;s somewhat reminiscent of this pixel noise I once reported working on another gtkagg problem. Interestingly, I'm seeing the same behavior with backend gtk and gtkagg. All of which is discouraging: we both see bugs but different ones on linux, the appearance of the bug is caused by adding a combobox which is not used (on my system), the bug appears on some platforms (linux) but not others (win) and it appears for both gtk and gtkagg. JDH http://old.nabble.com/gtkagg-pixel-buffer-bug-td18051692.html |
|
From: John H. <jd...@gm...> - 2010-07-13 02:00:29
|
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter <jd...@gm...> wrote: > All of which is discouraging: we both see bugs but different ones on > linux, the appearance of the bug is caused by adding a combobox which > is not used (on my system), the bug appears on some platforms (linux) > but not others (win) and it appears for both gtk and gtkagg. The last thing I'll add for now is that my bug, the black pixel noise (fills the axes window when motion starts in a zoom-to-rect event) which may be unrelated to your bug, is happening in backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of calls: # this is used to copy the background that the zoom to rect "rubberband" will be drawn over self._imageBack = axrect, drawable.get_image(*axrect) # this is used to restore the background before redrawing the rectangle for the zoom box drawable.draw_image(gc, imageBack, 0, 0, *lastrect) Since the bug is only exposed when a combo box is added to the hierarchy, and appears to be platform or gtk specific, I'm suspecting a gtk bug at this point. But I don't have anything conclusive or a minimal example which I could use to post to the gtk list. The mpl calls and values (axrect, lastrect, etc) look correct on inspection. Somehow the call to drawable.get_image is getting a buffer full of noise if and only if the combobox is added to the vbox. JDH |
|
From: João L. S. <js...@fc...> - 2010-07-13 09:43:31
Attachments:
plot_moves2.py
plot_moves2.png
|
On 07/13/2010 02:05 AM, John Hunter wrote: > I also see buggy behavior, but on my ubuntu linux system I see that > the whole subplot gets painted black on a mouse press and remains so > while the rubber-banding is in effect. It's not strictly black, but > it looks like blackish bit noise. I also notice if I don't add the > combobox to the vbox, I have no problem. But I don't see that the > "plot moves".... By the plot moves, I mean that with a reasonably sized control on top of the plot the lower x axis seems to shoot upward during the zoom. See the attached example. > > It;s somewhat reminiscent of this pixel noise I once reported working > on another gtkagg problem. > > Interestingly, I'm seeing the same behavior with backend gtk and gtkagg. > > All of which is discouraging: we both see bugs but different ones on > linux, Actually I think we are seeing the same bug (the blackish noise). I've included screen shots both on the original post and this one so you can see what happens while the mouse is pressed. >the appearance of the bug is caused by adding a combobox which > is not used (on my system), the bug appears on some platforms (linux) > but not others (win) and it appears for both gtk and gtkagg. > I agree with you that it does look like a gtk bug, although it's not ComboBox specific, as the example attached to this message uses a Label. JLS |
|
From: Preben R. <ra...@pv...> - 2010-07-13 10:23:39
|
> On 07/13/2010 02:05 AM, John Hunter wrote: >> I also see buggy behavior, but on my ubuntu linux system I see that >> the whole subplot gets painted black on a mouse press and remains so >> while the rubber-banding is in effect. It's not strictly black, but >> it looks like blackish bit noise. I also notice if I don't add the >> combobox to the vbox, I have no problem. But I don't see that the >> "plot moves".... > > By the plot moves, I mean that with a reasonably sized control on top of > the plot the lower x axis seems to shoot upward during the zoom. See the > attached example. I see the same moving on one of my PCs (64-bit) in Ubuntu 10.04. But the movement is much larger. |
|
From: João L. S. <js...@fc...> - 2010-07-24 17:18:31
Attachments:
gtk_rubberband.diff
|
On 07/13/2010 02:31 AM, John Hunter wrote: > On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jd...@gm...> wrote: >> All of which is discouraging: we both see bugs but different ones on >> linux, the appearance of the bug is caused by adding a combobox which >> is not used (on my system), the bug appears on some platforms (linux) >> but not others (win) and it appears for both gtk and gtkagg. > > The last thing I'll add for now is that my bug, the black pixel noise > (fills the axes window when motion starts in a zoom-to-rect event) > which may be unrelated to your bug, is happening in > backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of > calls: > > # this is used to copy the background that the zoom to rect > "rubberband" will be drawn over > self._imageBack = axrect, drawable.get_image(*axrect) > > # this is used to restore the background before redrawing the > rectangle for the zoom box > drawable.draw_image(gc, imageBack, 0, 0, *lastrect) > > Since the bug is only exposed when a combo box is added to the > hierarchy, and appears to be platform or gtk specific, I'm suspecting > a gtk bug at this point. But I don't have anything conclusive or a > minimal example which I could use to post to the gtk list. The mpl > calls and values (axrect, lastrect, etc) look correct on inspection. > Somehow the call to drawable.get_image is getting a buffer full of > noise if and only if the combobox is added to the vbox. > > JDH From what I could understand from the pygtk documentation get_image / draw_image are client-side operations. In particular: "If the source drawable is a Gdk::Window and partially offscreen or obscured, then the obscured portions of the returned image will contain undefined data." Anyway they recommend using Pixmap, which is server-side and a offscreen drawable. I've attached a patch that replaces the get_image / draw_image with Pixmap operations and fixes this bug. I've tested this patch on Linux and Windows. Regards, João Luís |
|
From: Benjamin R. <ben...@ou...> - 2010-07-24 18:56:29
|
On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <js...@fc...> wrote: > On 07/13/2010 02:31 AM, John Hunter wrote: > >> On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jd...@gm...> wrote: >> >>> All of which is discouraging: we both see bugs but different ones on >>> linux, the appearance of the bug is caused by adding a combobox which >>> is not used (on my system), the bug appears on some platforms (linux) >>> but not others (win) and it appears for both gtk and gtkagg. >>> >> >> The last thing I'll add for now is that my bug, the black pixel noise >> (fills the axes window when motion starts in a zoom-to-rect event) >> which may be unrelated to your bug, is happening in >> backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of >> calls: >> >> # this is used to copy the background that the zoom to rect >> "rubberband" will be drawn over >> self._imageBack = axrect, drawable.get_image(*axrect) >> >> # this is used to restore the background before redrawing the >> rectangle for the zoom box >> drawable.draw_image(gc, imageBack, 0, 0, *lastrect) >> >> Since the bug is only exposed when a combo box is added to the >> hierarchy, and appears to be platform or gtk specific, I'm suspecting >> a gtk bug at this point. But I don't have anything conclusive or a >> minimal example which I could use to post to the gtk list. The mpl >> calls and values (axrect, lastrect, etc) look correct on inspection. >> Somehow the call to drawable.get_image is getting a buffer full of >> noise if and only if the combobox is added to the vbox. >> >> JDH >> > > From what I could understand from the pygtk documentation get_image / > draw_image are client-side operations. In particular: > > "If the source drawable is a Gdk::Window and partially offscreen or > obscured, then the obscured portions of the returned image will contain > undefined data." > > Anyway they recommend using Pixmap, which is server-side and a offscreen > drawable. I've attached a patch that replaces the get_image / draw_image > with Pixmap operations and fixes this bug. I've tested this patch on Linux > and Windows. > > Regards, > João Luís > The patch works for me. I am using the mpl from svn. Ben Root |
|
From: John H. <jd...@gm...> - 2010-07-24 20:11:52
|
On Sat, Jul 24, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote: > On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <js...@fc...> wrote: >> >> On 07/13/2010 02:31 AM, John Hunter wrote: >>> >>> On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jd...@gm...> wrote: >>>> >>>> All of which is discouraging: we both see bugs but different ones on >>>> linux, the appearance of the bug is caused by adding a combobox which >>>> is not used (on my system), the bug appears on some platforms (linux) >>>> but not others (win) and it appears for both gtk and gtkagg. >>> >>> The last thing I'll add for now is that my bug, the black pixel noise >>> (fills the axes window when motion starts in a zoom-to-rect event) >>> which may be unrelated to your bug, is happening in >>> backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of >>> calls: >>> >>> # this is used to copy the background that the zoom to rect >>> "rubberband" will be drawn over >>> self._imageBack = axrect, drawable.get_image(*axrect) >>> >>> # this is used to restore the background before redrawing the >>> rectangle for the zoom box >>> drawable.draw_image(gc, imageBack, 0, 0, *lastrect) >>> >>> Since the bug is only exposed when a combo box is added to the >>> hierarchy, and appears to be platform or gtk specific, I'm suspecting >>> a gtk bug at this point. But I don't have anything conclusive or a >>> minimal example which I could use to post to the gtk list. The mpl >>> calls and values (axrect, lastrect, etc) look correct on inspection. >>> Somehow the call to drawable.get_image is getting a buffer full of >>> noise if and only if the combobox is added to the vbox. >>> >>> JDH >> >> >From what I could understand from the pygtk documentation get_image / >> draw_image are client-side operations. In particular: >> >> "If the source drawable is a Gdk::Window and partially offscreen or >> obscured, then the obscured portions of the returned image will contain >> undefined data." >> >> Anyway they recommend using Pixmap, which is server-side and a offscreen >> drawable. I've attached a patch that replaces the get_image / draw_image >> with Pixmap operations and fixes this bug. I've tested this patch on Linux >> and Windows. >> >> Regards, >> João Luís > > The patch works for me. I am using the mpl from svn. Have you tested with any of the animation and blit examples? How about some of the widget examples? If all these work for you, I suggest committing it to the branch and merging to the trunk. Thanks, JDH |
|
From: Benjamin R. <ben...@ou...> - 2010-07-25 20:15:16
|
On Sat, Jul 24, 2010 at 3:11 PM, John Hunter <jd...@gm...> wrote: > On Sat, Jul 24, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote: > > On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <js...@fc...> > wrote: > >> > >> On 07/13/2010 02:31 AM, John Hunter wrote: > >>> > >>> On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jd...@gm...> > wrote: > >>>> > >>>> All of which is discouraging: we both see bugs but different ones on > >>>> linux, the appearance of the bug is caused by adding a combobox which > >>>> is not used (on my system), the bug appears on some platforms (linux) > >>>> but not others (win) and it appears for both gtk and gtkagg. > >>> > >>> The last thing I'll add for now is that my bug, the black pixel noise > >>> (fills the axes window when motion starts in a zoom-to-rect event) > >>> which may be unrelated to your bug, is happening in > >>> backend_gtk.NavigationToolbar2GTK.draw_rubberband in the pair of > >>> calls: > >>> > >>> # this is used to copy the background that the zoom to rect > >>> "rubberband" will be drawn over > >>> self._imageBack = axrect, drawable.get_image(*axrect) > >>> > >>> # this is used to restore the background before redrawing the > >>> rectangle for the zoom box > >>> drawable.draw_image(gc, imageBack, 0, 0, *lastrect) > >>> > >>> Since the bug is only exposed when a combo box is added to the > >>> hierarchy, and appears to be platform or gtk specific, I'm suspecting > >>> a gtk bug at this point. But I don't have anything conclusive or a > >>> minimal example which I could use to post to the gtk list. The mpl > >>> calls and values (axrect, lastrect, etc) look correct on inspection. > >>> Somehow the call to drawable.get_image is getting a buffer full of > >>> noise if and only if the combobox is added to the vbox. > >>> > >>> JDH > >> > >> >From what I could understand from the pygtk documentation get_image / > >> draw_image are client-side operations. In particular: > >> > >> "If the source drawable is a Gdk::Window and partially offscreen or > >> obscured, then the obscured portions of the returned image will contain > >> undefined data." > >> > >> Anyway they recommend using Pixmap, which is server-side and a offscreen > >> drawable. I've attached a patch that replaces the get_image / draw_image > >> with Pixmap operations and fixes this bug. I've tested this patch on > Linux > >> and Windows. > >> > >> Regards, > >> João Luís > > > > The patch works for me. I am using the mpl from svn. > > Have you tested with any of the animation and blit examples? How > about some of the widget examples? If all these work for you, I > suggest committing it to the branch and merging to the trunk. > > Thanks, > JDH > I tried a bunch of the animation examples and widget examples with and without the patch. I could not find one that was affected by this bug, however, none of them were adversely affected by the patch. However, both of the plot_moves.py scripts were improved by the patch. Ben Root |
|
From: John H. <jd...@gm...> - 2010-07-25 22:05:08
|
On Sun, Jul 25, 2010 at 3:14 PM, Benjamin Root <ben...@ou...> wrote: > I tried a bunch of the animation examples and widget examples with and > without the patch. I could not find one that was affected by this bug, > however, none of them were adversely affected by the patch. However, both > of the plot_moves.py scripts were improved by the patch. Since this is a bugfix, it should go into the 1.0 release branch and then merged into the trunk using svnmerge. Are you familar with this (it's described in the coding guide). If so, would you mind committing this? Thanks for the testing Ben and the patch João JDH |
|
From: Benjamin R. <ben...@ou...> - 2010-07-25 22:50:11
|
On Sun, Jul 25, 2010 at 5:04 PM, John Hunter <jd...@gm...> wrote: > On Sun, Jul 25, 2010 at 3:14 PM, Benjamin Root <ben...@ou...> wrote: > > I tried a bunch of the animation examples and widget examples with and > > without the patch. I could not find one that was affected by this bug, > > however, none of them were adversely affected by the patch. However, > both > > of the plot_moves.py scripts were improved by the patch. > > Since this is a bugfix, it should go into the 1.0 release branch and > then merged into the trunk using svnmerge. Are you familar with this > (it's described in the coding guide). If so, would you mind > committing this? > > Thanks for the testing Ben and the patch João > > JDH > Sure, I can commit it. committed to v1.0 branch as r8575 and merged with trunk as r8576. Ben Root |
