Re: [platform-swt-dev] GTK:How to force a shell to paint?

[Havoc Pennington <hp@xxxxxxxxxx>]

Steve_Northover@xxxxxxx writes:
> Doesn't seem to work.  Here is some example code.
> BTW:  You are my hero for your post about the "sucky API's".
> Way to tell 'em!

Heh ;-)
 
> public static void main (String [] args) {
>         int width = 32, height = 32;
>         OS.gtk_init_check (new int [] {0}, null);
>         int shellHandle = OS.gtk_window_new (OS.GTK_WINDOW_TOPLEVEL);
>         OS.gtk_widget_show_now (shellHandle);
>  
> //      Neither call one works
> //      OS.gdk_window_process_updates (window, false);
>         OS.gdk_window_process_all_updates ();
> 
> //      Works but processes too many events
> //      while (OS.gtk_events_pending () != 0) OS.gtk_main_iteration (); 
>

Hmm, I think I know what's wrong.

process_updates() is sending exposes to GTK for the current damage
region.

X expose events normally just add to the damage region.

So the process_updates() does nothing because the X exposes are still
in the event queue, and the damage region is empty.

Note that gtk_widget_show_now() does the gtk_main_iteration() stuff,
so you are already reentrant in this function.

I'm not really sure what to do except step back to a bigger picture
and try to think of another approach - the usual alternative is to
think of a scary hack, but I'm not really coming up with one.

Owen says he wants to do the above by default for override redirect
windows in the future, so that apps go ahead and redraw the window
without waiting for the exposes to come back, which speeds things
up. But that won't work for normal windows since you have to wait for
the MapNotify in order to know it's possible to draw (since the window
manager is involved).

This leads me on a funny tangent train of thought, which is that
occasionally window managers will not map a window when it's first
shown (for example if you show a dialog it goes on its parent window's
workspace, so may not be mapped if the user isn't on that workspace).
In that case gtk_widget_show_now() probably blocks in the main loop
until the user switches workspaces. I wonder if that breaks
anything...


OK rambling back around to the point, here's a possible hack - what if
you did "while (gdk_events_pending ()) gtk_main_iteration()" - note
gdk_events not gtk_events. Then you would only run the main loop until
all GDK events had come through, you wouldn't do as many other
things. Other things at equal or higher priority than the event queue
would still be processed, but you wouldn't for example run any idle
functions. So maybe that's good enough.

Havoc