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
plot_moves.py (1.25 KB)
You have this line:
from widgets import Widgets
what is "widgets" ?
JDH
···
On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <jsilva@...668...> 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).
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
···
On Mon, Jul 12, 2010 at 6:39 PM, João Luís Silva <jsilva@...668...> wrote:
John Hunter wrote:
On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva >> <jsilva-BxEiAy0842I@...1455...> 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)
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
···
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter <jdh2358@...287...> 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.
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
plot_moves2.py (1.09 KB)
···
On 07/13/2010 02:05 AM, John Hunter wrote:
I see the same moving on one of my PCs (64-bit) in Ubuntu 10.04. But the
movement is much larger.
···
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.
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
gtk_rubberband.diff (1.32 KB)
···
On 07/13/2010 02:31 AM, John Hunter wrote:
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jdh2358@...287...> 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
The patch works for me. I am using the mpl from svn.
Ben Root
···
On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <jsilva@…3054…68…> wrote:
On 07/13/2010 02:31 AM, John Hunter wrote:
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jdh2358@…287…> 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
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
···
On Sat, Jul 24, 2010 at 1:56 PM, Benjamin Root <ben.root@...1304...> wrote:
On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <jsilva@...668...> wrote:
On 07/13/2010 02:31 AM, John Hunter wrote:
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jdh2358@...287...> 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.
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
···
On Sat, Jul 24, 2010 at 3:11 PM, John Hunter <jdh2358@…287…> wrote:
On Sat, Jul 24, 2010 at 1:56 PM, Benjamin Root <ben.root@…1304…> wrote:
On Sat, Jul 24, 2010 at 12:17 PM, João Luís Silva <jsilva@…668…> wrote:
On 07/13/2010 02:31 AM, John Hunter wrote:
On Mon, Jul 12, 2010 at 8:05 PM, John Hunter<jdh2358@…287…> 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
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
···
On Sun, Jul 25, 2010 at 3:14 PM, Benjamin Root <ben.root@...1304...> 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.
Sure, I can commit it.
committed to v1.0 branch as r8575
and merged with trunk as r8576.
Ben Root
···
On Sun, Jul 25, 2010 at 5:04 PM, John Hunter <jdh2358@…287…> wrote:
On Sun, Jul 25, 2010 at 3:14 PM, Benjamin Root <ben.root@…1304…> 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
