Re: How to get notified when a GdkWindow becomes hidden/invisible/unrealized?

[Michael Ekstrand <mekstran scl ameslab gov>]

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