On Jul 6, 2006, at 8:55 AM, Clemens Eisserer wrote: > Yes this was also the problem I faced, I read about these signals in > GTKs documentation but desperatly tried to find a way for listenig > these events in Gdk. > Any hints about that, maybe someone else could help *please*, I just > don't know enough about GTK *ashamed* :-/ Mark's suggestion in the other thread of using gdk_window_add_filter is probably the canonical way to do it. However, it seems to be more for filtering and remapping events - it may not provide what you need. It also may not let you hook in after the GTK world has processed the signal, and it'd probably be best to destroy things only after GTK is done running code. What I was thinking (and this could be a really bad idea) is modifying the GdkWindow internal functions that deal with and/or propagate this event if possible. I'm not quite sure how GdkWindow objects tie in with the event loop, or what code is responsible for making sure that the appropriate X events find their way to the approprate GTK objects. A couple promising functions are in gdk/x11/gdkwindow-x11.c: pre_unmap and post_unmap. If the unmap event indeed does get fired at a useful time, you may be able to patch post_unmap to do what you need. I did a little searching for visibility stuff in there, and didn't find anything useful-looking; that doesn't mean there isn't. So, basically, you shouldn't look for a way to listen to the signals from within GDK - you need to look for a way to interact with the events causing these signals *before* (or after, depending on what you need) they reach GTK. So, conceptually, if there exists some code: do_gdk_stuff give_gtk_the_event do_more_gdk_stuff then you can modify either gdk_stuff entry to handle things in GDK. I'm not familiar enough with GDK's internals or with how it interacts with GTK to be able to say for sure that this will work, or is feasible, but it would be what I would try to do first, at least. It may be a bad idea, but heh, if it works, it might at least light a fire under someone else to use the fixes (or rework them to do things The Right Way, if they show demonstrable improvements). >> HTH, and I hope you have some good success in improving GTK's redraw >> performance. > Well gtkperf showed a 35% improvement just beceuase of modifications > in the double-buffer code on nvidia graphics hardware :-) Excellent :-) - Michael _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
