Thread: Re: [Matplotlib-users] Re: [pygtk] Gtk.Notebook problem in PyGTK 2.6

On Wed, 2005-06-01 at 05:12 -0700, matplotlib-users-
re...@li... wrote:
> > I made a small test app which clearly shows that Matplotlib 0.8 and
> > PyGTK 2.6 don't work well together. No problem in PyGTK 2.4
> > 
> > bye,
> > Dimtiri

I have problems with it in PyGTK 2.4

$ python testMPL-GTK.py
(testMPL-GTK.py:12685): libglade-WARNING **: unknown property
`focus_on_map' for class `GtkWindow'

(testMPL-GTK.py:12685): libglade-WARNING **: unknown property
`ellipsize' for class `GtkLabel'
...

I then click on the 'graph' Tab and the 'make graph!' button and get:
Traceback (most recent call last):
  File "testMPL-GTK.py", line 55, in createProjectGraph
    p1 = self.axis.bar(ind, int(age), width, color='r')
ValueError: invalid literal for int():


Do you think this is a gtk.Notebook problem or a matplotlib
FigureCanvasGTK widget problem?
If its a FigureCanvasGTK problem then you should be able to forget about
the gtk.Notebook and run
matplotlib/examples/embedding_in_gtk.py, or 
matplotlib/examples/embedding_in_gtk2.py and demonstrate the problem.

Try running embedding_in_gtk.py and moving another window partly in
front of it, then click the embedding_in_gtk window to bring it back on
top - does the window get redrawn?

I can verify that on PyGTK 2.4 on Linux it works fine.
Could you test it on PyGTK 2.6, and also report the operating system you
are using.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Try running embedding_in_gtk.py and moving another window
    Steve> partly in front of it, then click the embedding_in_gtk
    Steve> window to bring it back on top - does the window get
    Steve> redrawn?

    Steve> I can verify that on PyGTK 2.4 on Linux it works fine.
    Steve> Could you test it on PyGTK 2.6, and also report the
    Steve> operating system you are using.

I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
normal mpl pylab figure in GTKAgg.  It is hard to see with normal
figure sizes, because the tooltips by default appear below the toolbar
and thus do not occlude the FigureCanvas, but if you resize the figure
so that it takes up the entire vertical extent of the desktop, and
then hover over the toolbar, the tooltips will occlude the canvas and
will expose the bug -- no pun intended :-)  The basic problem is that
the area occluded by the tooltip is not redrawn when, for example, you
hover over a different toolbar button.

JDH

John Hunter schrieb:

>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>>            
>>>>>>
>
>    Steve> Try running embedding_in_gtk.py and moving another window
>    Steve> partly in front of it, then click the embedding_in_gtk
>    Steve> window to bring it back on top - does the window get
>    Steve> redrawn?
>
>    Steve> I can verify that on PyGTK 2.4 on Linux it works fine.
>    Steve> Could you test it on PyGTK 2.6, and also report the
>    Steve> operating system you are using.
>
>I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
>normal mpl pylab figure in GTKAgg.  It is hard to see with normal
>figure sizes, because the tooltips by default appear below the toolbar
>and thus do not occlude the FigureCanvas, but if you resize the figure
>so that it takes up the entire vertical extent of the desktop, and
>then hover over the toolbar, the tooltips will occlude the canvas and
>will expose the bug -- no pun intended :-)  The basic problem is that
>the area occluded by the tooltip is not redrawn when, for example, you
>hover over a different toolbar button.
>
>JDH
>  
>
As I mentioned in my post in the original thread the reason for this 
lies in the fact that you turn off GTK double buffering and try to 
provide your own buffering mechanism.  Why can't you use both? From my 
first impression there seems to be no speed problems when I turn gtk 
double buffering on, but all the mentioned problems will be gone.

Niklas.

On Wed, 2005-06-01 at 20:44 -0500, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> Try running embedding_in_gtk.py and moving another window
>     Steve> partly in front of it, then click the embedding_in_gtk
>     Steve> window to bring it back on top - does the window get
>     Steve> redrawn?
> 
>     Steve> I can verify that on PyGTK 2.4 on Linux it works fine.
>     Steve> Could you test it on PyGTK 2.6, and also report the
>     Steve> operating system you are using.
> 
> I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
> normal mpl pylab figure in GTKAgg.  It is hard to see with normal
> figure sizes, because the tooltips by default appear below the toolbar
> and thus do not occlude the FigureCanvas, but if you resize the figure
> so that it takes up the entire vertical extent of the desktop, and
> then hover over the toolbar, the tooltips will occlude the canvas and
> will expose the bug -- no pun intended :-)  The basic problem is that
> the area occluded by the tooltip is not redrawn when, for example, you
> hover over a different toolbar button.
> 
> JDH

I've taken the pygtk list off of the reply-to addresses, I don't think
its their problem anymore.

I updated backend_gtk.py in cvs to remove the DBL_BUFFER code - it was
just an experimental feature and I do not think anyone had a use for it,
and it was confusing the rest of the code.
I added the call to self.window.clear_area() which should solve the
problem. Could someone using PyGTK 2.6 install from cvs and let me know
if it works.

Thanks,
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I updated backend_gtk.py in cvs to remove the DBL_BUFFER
    Steve> code - it was just an experimental feature and I do not
    Steve> think anyone had a use for it, and it was confusing the
    Steve> rest of the code.  I added the call to
    Steve> self.window.clear_area() which should solve the
    Steve> problem. Could someone using PyGTK 2.6 install from cvs and
    Steve> let me know if it works.


These changes fixed the problem for 2.6.

Thanks Steve!

JDH

Thanks to you all, this is another example how open source software works.=
=20
We tend to take it for granted now, but actually... it is amazing!

thanks,
Dimitri

On 6/3/05, John Hunter <jdh...@ac...> wrote:
>=20
> >>>>> "Steve" =3D=3D Steve Chaplin <ste...@ya...> writes:
>=20
> Steve> I updated backend_gtk.py in cvs to remove the DBL_BUFFER
> Steve> code - it was just an experimental feature and I do not
> Steve> think anyone had a use for it, and it was confusing the
> Steve> rest of the code. I added the call to
> Steve> self.window.clear_area() which should solve the
> Steve> problem. Could someone using PyGTK 2.6 install from cvs and
> Steve> let me know if it works.
>=20
>=20
> These changes fixed the problem for 2.6.
>=20
> Thanks Steve!
>=20
> JDH
>=20
>=20
> -------------------------------------------------------
> This SF.Net <http://SF.Net> email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>=20



--=20
Please visit dimitri's website: www.serpia.com <http://www.serpia.com>

On Wed, 2005-06-01 at 05:12 -0700, matplotlib-users-
re...@li... wrote:
> I have started looking at the code and did not quite understand what I 
> found:
> 
> backends/backend_gtk.py has a class FigureCanvasGTK. Its method 
> 'expose_event' is responsible for redrawing.
> In the situation I described, when I leave an opened menu that overlaps 
> the graph, the expose_event is properly called, but the widget is not 
> redrawn. If DBL_BUFFER is set (which it is), the widget is only redrawn, 
> if self._draw_pixmap is set to True. 
Thats not true, see below.
> Of course, this variable is not set 
> to True when GTK closes a menu but only when matplotlib requests a 
> redraw.  So, in conclusion, no redraw happens.
> 
> After consulting the PyGTK reference I tried to reactivate double 
> buffering, which is turned of in the backend_gtk.py by the command
> 
> self.set_double_buffered(False)
> 
> I wonder why you set this? Do you want to provide your own double 
> buffering? Why? If you set this value to True, everything will be fine.
> 
> Best regards,
> 
> Niklas Volbers.

Why do we have self.set_double_buffered(False)?
Its been that way for as long as I can remember, I think John wrote the
original code, he may remember the actual reasons.

My guess is because of printing. backend_gtk has two basic functions -
to plot to the display and to plot to a file. If you 
set_double_buffered(False) you can draw to a Pixmap and use the pixmap
to draw to both the screen and to a jpg or png file.
If you draw direct to a gdk.Window you can only save to a file if the
gdk.Window is mapped; if the window is minimised or not yet realized the
print will fail. The 'savefig()' command would not work if called before
'show()'.

expose-events:
If the window is resized or draw() is called self._draw_pixmap is set to
True and the whole figure is redrawn to the Pixmap.
self.window.set_back_pixmap() is then called to set the window
background to the Pixmap. Then if an expose event occurs, without the
window being resized or draw() being called, matplotlib does not need to
do anything. GTK+ handles it for us by automatically filling an exposed
window with its background, which is our plot.

This is how it works for GTK+/PyGTK 2.4. However, something changed in
2.6 and it no longer always draws the widgets background. I think this
is a bug, however after rereading the gdk_window_set_back_pixmap()
manual page I notice it says:
"The windowing system will normally fill a window with its background
when the window is obscured then exposed, and when you call
gdk_window_clear()"

What is "normally" supposed to mean? It not something you can rely on,
so it may just as well be "never". I think that the documentation is
unclear and opened a documentation bug report
http://bugzilla.gnome.org/show_bug.cgi?id=306214

I also found a bug report very similar to the problem experienced in
matplotlib
http://bugzilla.gnome.org/show_bug.cgi?id=161561
its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may
work OK, and it may just have been a 2.6.0 problem.

Regards,
Steve


Send instant messages to your online friends http://au.messenger.yahoo.com 

Steve, thanks for your long reply. I think I know understand the way it 
works.


Steve Chaplin schrieb:

> [...] 
> expose-events:
> If the window is resized or draw() is called self._draw_pixmap is set to
> True and the whole figure is redrawn to the Pixmap.
> self.window.set_back_pixmap() is then called to set the window
> background to the Pixmap. Then if an expose event occurs, without the
> window being resized or draw() being called, matplotlib does not need to
> do anything. GTK+ handles it for us by automatically filling an exposed
> window with its background, which is our plot.
> 
> This is how it works for GTK+/PyGTK 2.4. However, something changed in
> 2.6 and it no longer always draws the widgets background. I think this
> is a bug, however after rereading the gdk_window_set_back_pixmap()
> manual page I notice it says:
> "The windowing system will normally fill a window with its background
> when the window is obscured then exposed, and when you call
> gdk_window_clear()"

I read that part too, but didn not quite understand it before you 
explained the part about set_back_pixmap().

> What is "normally" supposed to mean? It not something you can rely on,
> so it may just as well be "never". I think that the documentation is
> unclear and opened a documentation bug report
> http://bugzilla.gnome.org/show_bug.cgi?id=306214
> 
> I also found a bug report very similar to the problem experienced in
> matplotlib
> http://bugzilla.gnome.org/show_bug.cgi?id=161561
> its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may
> work OK, and it may just have been a 2.6.0 problem.

Hmmm. The buggy behaviour I noticed was on a machine running pygtk 2.6.1 
and gtk+-2.6.4, so I am not so sure if it was a 2.6.0 problem.

Niklas Volbers.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Why do we have self.set_double_buffered(False)?  Its been
    Steve> that way for as long as I can remember, I think John wrote
    Steve> the original code, he may remember the actual reasons.

The original motivation can be found in this thread

  http://www.daa.com.au/pipermail/pygtk/2003-May/005229.html

The basic idea, if I recall correctly, was that since I was already
drawing to a pixmap, I was duplicating some effort by turning on
double buffering.  Perhaps this reasoning wasn't correct, since we
were clearly doing something wrong as evidenced by the bug report that
started this discussion.


JDH

On Fri, 2005-06-03 at 08:00 -0500, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> Why do we have self.set_double_buffered(False)?  Its been
>     Steve> that way for as long as I can remember, I think John wrote
>     Steve> the original code, he may remember the actual reasons.
> 
> The original motivation can be found in this thread
> 
>   http://www.daa.com.au/pipermail/pygtk/2003-May/005229.html
> 
> The basic idea, if I recall correctly, was that since I was already
> drawing to a pixmap, I was duplicating some effort by turning on
> double buffering.  Perhaps this reasoning wasn't correct, since we
> were clearly doing something wrong as evidenced by the bug report that
> started this discussion.
The bug report highlights a GTK+ 2.6 bug (in my opinion) - GTK should
redraw a widgets background after each expose event, it does for 2.4 but
forgets to do it for 2.6.

It looks like the gdk.Pixmap was used to solve the screen flicker
problem. However, if you arrange for all drawing to go through the
expose_event function (instead of a custom 'draw' function), GTK should
ensure there is no flicker (at least thats what the
gtk_widget_set_double_buffered documentation suggests).

But using a Pixmap has the advantage that you can quickly redraw a part
of the window that has been obscured and then exposed without needing to
redraw the entire Figure.

Regards
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>=20
>=20
> I then click on the 'graph' Tab and the 'make graph!' button and get:
> Traceback (most recent call last):
> File "testMPL-GTK.py", line 55, in createProjectGraph
> p1 =3D self.axis.bar(ind, int(age), width, color=3D'r')
> ValueError: invalid literal for int():


You should enter two values before creating the graph (use the two text=20
entries located above the button)
It should work then
(remember, this only a test app)
Thnaks for trying,
Dimitri