Re: [pygtk] High CPU with expose-event
Sæl ! I tried my example but without any sucess as the area is not suppose to have that method ! Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.window.signal_handler_block(self.signal_id) AttributeError: 'gtk.gdk.Window' object has no attribute 'signal_handler_block' I even tried with the window from area Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.window.signal_handler_block(self.signal_id) AttributeError: 'gtk.gdk.Window' object has no attribute 'signal_handler_block' What has the signal_handler_block method ? Any other idea on the way to proceed ? Takk Jean-Baptiste On Fri, 5 Dec 2003 16:32:03 -0200 Christian Robottom Reis [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 06:13:06PM +, Jean-Baptiste Cazier wrote: After further investigation it seems that the routine called by my expose_event signal is generating itself new expose_event... That's definitely not a good thing :-) To avoid that effect I would like to block the signal when entering the routine and unblock it while leaving but I have problem transferring the event id through the routine itself and to knwo to what I should apply it to How should i use signal_handler_block ? Just store the event id in an instance or module variable (you could get fancy and store it as widget data, if you really wanted to avoid the external variable). You should block the signal handler any time it risks recursing. def area_expose_cb(self, area, event): Update the DrawingArea area.signal_handler_block(signal_id) ... Do something on the Drawing Area ... area.signal_handler_unblock(signal_id) return gtk.TRUE Looks correct to me. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 -- - [EMAIL PROTECTED] Department of Statistics deCODE genetics Sturlugata,8 570 2993 101 Reykjavík ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Fw: gtk for Python
On Fri, 2003-12-05 at 12:27, GopinathR wrote:
These are the following steps which I carried out.
1.http://www.pcpm.ucl.ac.be/~gustin/win32_ports/binaries/pygtk-2.0.0.win32-p
y2.3.exe
2.http://prdownloads.sourceforge.net/gtk-win --
(GTK-Runtime-Environment-2.2.4.1.exe)
By doing this, I could able to do
import pygtk
pygtk.require('2.0' )
import gtk
But I could only get only (gtk.TRUE and gtk.FALSE) , I could not able to get
gtk.Window, gtk.Frame etc.. which is what I want for developing GUI.
Are you sure your PATH is set appropriately ?
No leftover DLLs in Windows/system32 from a previous installation ?
Please check
http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq21.002.htp
for details.
Cedric
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
On Mon, Dec 08, 2003 at 09:50:30AM +, Jean-Baptiste Cazier wrote: I tried my example but without any sucess as the area is not suppose to have that method ! Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.window.signal_handler_block(self.signal_id) ^ You should block on the area itself, not its window. (That said, I'm not positive this will work at all.) AttributeError: 'gtk.gdk.Window' object has no attribute 'signal_handler_block' Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
Sael ! Thanks again for the interest you give to my development :) As I stated in my e-mail I started with the area itself without sucess. Then I tried with its associated window, but none of them have the block event installed But I realise I put the wrong output line in my e-mail :( area expose cb GdkRectangle at 0x81fa890 0 __main__.DrawingArea instance at 0x863e97c GdkEvent at 0xbfffdaa0 gtk.DrawingArea object (GtkDrawingArea) at 0x8513c04 Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.signal_handler_block(self.signal_id) AttributeError: 'gtk.DrawingArea' object has no attribute 'signal_handler_block' Also the area itself does not have the attribute ! Takk JB On Mon, 8 Dec 2003 10:14:36 -0200 Christian Robottom Reis [EMAIL PROTECTED] wrote: On Mon, Dec 08, 2003 at 09:50:30AM +, Jean-Baptiste Cazier wrote: I tried my example but without any sucess as the area is not suppose to have that method ! Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.window.signal_handler_block(self.signal_id) ^ You should block on the area itself, not its window. (That said, I'm not positive this will work at all.) AttributeError: 'gtk.gdk.Window' object has no attribute 'signal_handler_block' Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 -- - [EMAIL PROTECTED] Department of Statistics deCODE genetics Sturlugata,8 570 2993 101 Reykjavík ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
On Mon, Dec 08, 2003 at 12:47:39PM +, Jean-Baptiste Cazier wrote: But I realise I put the wrong output line in my e-mail :( area expose cb GdkRectangle at 0x81fa890 0 __main__.DrawingArea instance at 0x863e97c GdkEvent at 0xbfffdaa0 gtk.DrawingArea object (GtkDrawingArea) at 0x8513c04 Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.signal_handler_block(self.signal_id) AttributeError: 'gtk.DrawingArea' object has no attribute 'signal_handler_block' Also the area itself does not have the attribute ! That's odd. In the 0.6 line, all GtkObjects have a signal_handler_block() method: a = gtk.GtkDrawingArea() a.connect(expose-event, foo) 1 a.signal_handler_block(1) This seems to have turned into handler_block in GObject: http://www.moeraki.com/pygtkreference/pygtk2reference/class-gobject.html Check it out and see if it gives you the expected results. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
Indeed I found there the handler_block command which actually exists However it did not solve my problem at all I even tried to the more direct disconnect at start and re-connection at the end of the routine but without further success I am quite disappointed I simply do not understand why the modification of the font makes a call to this routine self.area.modify_font(font_desc) JB On Mon, 8 Dec 2003 10:59:52 -0200 Christian Robottom Reis [EMAIL PROTECTED] wrote: On Mon, Dec 08, 2003 at 12:47:39PM +, Jean-Baptiste Cazier wrote: But I realise I put the wrong output line in my e-mail :( area expose cb GdkRectangle at 0x81fa890 0 __main__.DrawingArea instance at 0x863e97c GdkEvent at 0xbfffdaa0 gtk.DrawingArea object (GtkDrawingArea) at 0x8513c04 Traceback (most recent call last): File ./ldraw2.py, line 2884, in area_expose_cb area.signal_handler_block(self.signal_id) AttributeError: 'gtk.DrawingArea' object has no attribute 'signal_handler_block' Also the area itself does not have the attribute ! That's odd. In the 0.6 line, all GtkObjects have a signal_handler_block() method: a = gtk.GtkDrawingArea() a.connect(expose-event, foo) 1 a.signal_handler_block(1) This seems to have turned into handler_block in GObject: http://www.moeraki.com/pygtkreference/pygtk2reference/class-gobject.html Check it out and see if it gives you the expected results. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 -- - [EMAIL PROTECTED] Department of Statistics deCODE genetics Sturlugata,8 570 2993 101 Reykjavík ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
On Mon, Dec 08, 2003 at 01:24:41PM +, Jean-Baptiste Cazier wrote: Indeed I found there the handler_block command which actually exists However it did not solve my problem at all Hmm. Do you mean that even with handler_block() your callback is triggered by an expose-event? That's quite odd. Could it be that some other signal is triggering it too? I even tried to the more direct disconnect at start and re-connection at the end of the routine but without further success Are you *sure* you're running into a recursion here? It now sounds more like an emission that you're generating. If that's the case, what may be looking for an emit_stop_by_name(expose-event'). I am quite disappointed Take some time into studying the signal dynamics for your case, it's normally not too complex but can be hard to grasp at first. I simply do not understand why the modification of the font makes a call to this routine self.area.modify_font(font_desc) Hmmm, what do you mean by this? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
A Sex, 2003-12-05 às 18:13, Jean-Baptiste Cazier escreveu: hi ! After further investigation it seems that the routine called by my expose_event signal is generating itself new expose_event... To avoid that effect I would like to block the signal when entering the routine and unblock it while leaving but I have problem transferring the event id through the routine itself and to knwo to what I should apply it to How should i use signal_handler_block ? I would like to do somethhing like ... self.area = gtk.DrawingArea() self.area.add_events(gtk.gdk.POINTER_MOTION_MASK) self.area.add_events(gtk.gdk.BUTTON_RELEASE_MASK) self.area.add_events(gtk.gdk.BUTTON_PRESS_MASK ) singal_id=self.area.connect(expose-event, self.area_expose_cb) print id is , signal_id ... def area_expose_cb(self, area, event): Update the DrawingArea area.signal_handler_block(signal_id) ... Do something on the Drawing Area ... area.signal_handler_unblock(signal_id) return gtk.TRUE Any help would be appreciated Why complicate? Why not simply discard recursive expose events? I must say I find it very strange that gtk is sending expose events recursively. I _think_ that the only way this could happen would be if you were running the gtk main loop (or dialog.run) inside the expose event handler. This would be a Bad Idea (TM)! Anyway, an alternative to signal handler blocking, which doesn't seem to be working (I read down the thread), would be a simple trick of locking: def area_expose_cb(self, area, event): Update the DrawingArea if self.__area_expose_cb_lock: return True self.__area_expose_cb_lock = True ... Do something on the Drawing Area ... self.__area_expose_cb_lock = False return gtk.TRUE One more thing. If your struggling with complex drawings, you might want to use the gnome.Canvas widget instead. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] High CPU with expose-event
On Monday 08 December 2003 10:37 am, Gustavo J. A. M. Carneiro wrote: . This would be a Bad Idea (TM)! Anyway, an alternative to signal handler blocking, which doesn't seem to be working (I read down the thread), would be a simple trick of locking: def area_expose_cb(self, area, event): Update the DrawingArea if self.__area_expose_cb_lock: return True self.__area_expose_cb_lock = True ... Do something on the Drawing Area ... self.__area_expose_cb_lock = False return gtk.TRUE I've done similar things, only it was with mouse handling, and it worked very consistantly. ( Whenever the mouse was being moved, I needed to warp it back to the starting point, which generated another mouse event. ) I had to structure it a bit differently though, more like: #Ignores the next event, whether it is recursive or not. def handle_event( self, widget, event ): if self.locked: self.locked = false: return #stuff that might generated another event. self.locked = true I found (atleast with mouse events ) that emitting the new event signal didn't necessarily mean it would get processed right away, rather it is put on the event queue to get executed after the current event is finished, so it isn't recursive. Jon ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] pixbuf memory leak?
Sorry if this is a dupe but my message from last night didn't seem to make it on to the list. I'm trying to figure out how to use gtk.gdk.Pixbuf in such a way that it doesn't consume all the memory in the system. Part of my app is a list of thumbnail views of pictures each of which I create with sequence that look like this: for image_path in images: pb = gtk.gdk.pixbuf_new_from_file(image_path) npb = pb.scale_simple(thumb_width, thumb_height, gtk.gdk.INTERP_BILINEAR) thumb_list_model.set_value(thumb_list_model.append(None), 0, npb) The problem is that memory consumption seems to grow rapidly without bound making it useless for anything more than a half a dozen or so images. Is there some trick to tell the pixbuf to free it's memory or to tell python to free the pixbuf? I tried throwing in del pb at the end of the loop but it made no difference. When I get a chance I'm going to try to debug this and see if I can figure out if pyobject_dealloc is never being called or if it's somehow not freeing the memory. If someone has a suggestion for an easy way to do this debugging, let me know. My best idea so far is just to put some printf's in the key places of pygobject.c ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] How Do I Get gtk.gdk.Pixbuf to release memory?
I can't find anything in the API to tell it to let go and just letting pixbuf object go out of scope doesn't seem to do the trick. I have a picture thumbnail display list that just eats up memory until the OOM killer gets it. It loads the images using gtk.gdk.pixbuf_new_from_file and then creates a rescaled copy using scale_simple. The rescaled copy is then passed to an ListStore.append. I suppose it's possible that the (smaller) copy is somehow the same size as the original, which would explain the memory consumption, so the bug might be in scale_simple. But I was just wondering if this is a known problem or what. I can't find anything about it other than an unanswered message to this list a few months ago. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pixbuf memory leak?
Gary Herron wrote:
On Monday 08 December 2003 09:57 am, Jeff Bowden wrote:
Sorry if this is a dupe but my message from last night didn't seem to
make it on to the list.
I'm trying to figure out how to use gtk.gdk.Pixbuf in such a way that it
doesn't consume all the memory in the system. Part of my app is a list
of thumbnail views of pictures each of which I create with sequence that
look like this:
for image_path in images:
pb = gtk.gdk.pixbuf_new_from_file(image_path)
npb = pb.scale_simple(thumb_width, thumb_height,
gtk.gdk.INTERP_BILINEAR)
thumb_list_model.set_value(thumb_list_model.append(None), 0, npb)
The problem is that memory consumption seems to grow rapidly without
bound making it useless for anything more than a half a dozen or so images.
I hit this recently in a similar situation. My solution (actually
it's a workaround) was to use PIL (the Python Image Library) to read
and maniuplate the images. It's easy to draw a PIL image to a window:
image = Image.open('...')
simage = image.resize((...,...))
window.clear()
window.draw_rgb_image(... various parameters...,
gtk.gdk.RGB_DITHER_NONE,
simage.tostring(), -1, 0, 0)
I can do this process all day and not consume memory.
I'd prefer a solution, but this works fine for now.
Doesn't seem like that would work directly for my use of the GTK
TreeView. Hmmm, I wonder which will be more difficult, debugging pygtk
or making a custom cell renderer using PIL? Well, debugging seems like
the *right* solution so I think I'll try it first.
Are the pygtk developers on this list or is there a separate dev list
somewhere?
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pixbuf memory leak?
On Mon, Dec 08, 2003 at 10:47:47AM -0800, Jeff Bowden wrote: Are the pygtk developers on this list or is there a separate dev list somewhere? We're on the list, but we're hiding from you! More seriously, I've asked Gustavo and he says there doesn't appear to be a leak in your case -- it could just be a case of Python's interesting gc behaviour. So we're suggesting you add a gc.collect() call inside your loop and seeing if it improves. If it does, you're entitled to write a FAQ that explains your problem and solution wink. (If not, we'll still be hiding here if you need us.) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] How Do I Get gtk.gdk.Pixbuf to release memory?
A Seg, 2003-12-08 às 03:02, Jeff Bowden escreveu: I can't find anything in the API to tell it to let go and just letting pixbuf object go out of scope doesn't seem to do the trick. I have a picture thumbnail display list that just eats up memory until the OOM killer gets it. It loads the images using gtk.gdk.pixbuf_new_from_file and then creates a rescaled copy using scale_simple. The rescaled copy is then passed to an ListStore.append. I suppose it's possible that the (smaller) copy is somehow the same size as the original, which would explain the memory consumption, so the bug might be in scale_simple. But I was just wondering if this is a known problem or what. I can't find anything about it other than an unanswered message to this list a few months ago. I've add some instrumentation to the pixbuf wrapper code. Here's what I discovered: pb=gtk.gdk.pixbuf_new_from_file(/usr/share/pixmaps/gnome-emacs.png) ** Message: pixbuf 0x8154b48 created, grefcount=1 del pb import gc gc.collect() ** Message: pixbuf 0x8154b48 destroyed 1 The problem is that Python's garbage collector only kicks in after a certain amount of objects are in the 'garbage' list. So, you can explicitly call gc.collect() periodically, or you can change the gc threshold with gc.set_threshold(). I think that Python's gc module is tune for lots of objects taking small amount of memory each. In your case, you have few objects taking a huge amount of memory each. That's why the GC isn't working very well. I suggest you consult the documentation for the gc module. If you solve the problem, please let us know or write a small FAQ entry about it. Thanks! Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pixbuf memory leak?
Christian Robottom Reis wrote: On Mon, Dec 08, 2003 at 10:47:47AM -0800, Jeff Bowden wrote: Are the pygtk developers on this list or is there a separate dev list somewhere? We're on the list, but we're hiding from you! More seriously, I've asked Gustavo and he says there doesn't appear to be a leak in your case -- it could just be a case of Python's interesting gc behaviour. So we're suggesting you add a gc.collect() call inside your loop and seeing if it improves. If it does, you're entitled to write a FAQ that explains your problem and solution wink. (If not, we'll still be hiding here if you need us.) Thanks. It does appear that it is a python gc problem. Here's my new FAQ entry (still awaiting password): *23.16. Is there a resource leak? Why do I run out of memory using Pixbuf?* The answer is Interesting GC behaviour in Python. Apparently finalizers are not necessarily called as soon as an object goes out of scope. My guess is that the python memory manager doesn't directly know about the storage allocated for the image buffer (since it's allocated by the gdk) and that it therefor doesn't know how fast memory is being consumed. The solution is to call gc.collect() at some appropriate place. For example, I had some code that looked like this: for image_path in images: pb = gtk.gdk.pixbuf_new_from_file(image_path) npb = pb.scale_simple(thumb_width, thumb_height, gtk.gdk.INTERP_BILINEAR) thumb_list_model.set_value(thumb_list_model.append(None), 0, npb) This chewed up an unacceptably large amount of memory for any reasonable image set. Changing the code to look like this fixed the problem: for image_path in images: pb = gtk.gdk.pixbuf_new_from_file(image_path) npb = pb.scale_simple(thumb_width, thumb_height, gtk.gdk.INTERP_BILINEAR) thumb_list_model.set_value(thumb_list_model.append(None), 0, npb) gc.collect() gc.collect() ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pixbuf memory leak?
*23.16. Is there a resource leak? Why do I run out of memory using Pixbuf?* The answer is Interesting GC behaviour in Python. Apparently finalizers are not necessarily called as soon as an object goes out of scope. My guess is that the python memory manager doesn't directly know about the storage allocated for the image buffer (since it's allocated by the gdk) and that it therefor doesn't know how fast memory is being consumed. The solution is to call gc.collect() at some appropriate place. For example, I had some code that looked like this: for image_path in images: pb = gtk.gdk.pixbuf_new_from_file(image_path) npb = pb.scale_simple(thumb_width, thumb_height, gtk.gdk.INTERP_BILINEAR) thumb_list_model.set_value(thumb_list_model.append(None), 0, npb) This chewed up an unacceptably large amount of memory for any reasonable image set. Changing the code to look like this fixed the problem: for image_path in images: pb = gtk.gdk.pixbuf_new_from_file(image_path) npb = pb.scale_simple(thumb_width, thumb_height, gtk.gdk.INTERP_BILINEAR) thumb_list_model.set_value(thumb_list_model.append(None), 0, npb) gc.collect() gc.collect() Nice work. (And especially better than my work-around!) Gary Herron ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
