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] 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/
Re: [pygtk] High CPU with expose-event
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 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
