Re: Is there any way, api call, to make sure queued/pending redraws are completed

[Havoc Pennington <hp redhat com>]

"Norman Black" <stonybrk ix netcom com> writes:
> I am looking for the equivalent of the Win32 UpdateWindow API call. Since
> GTK delays repaint operations I would like to be able to guarantee that all
> updates are done before using a call like gdk_window_copy_area. This really
> only concerns my GtkDrawingArea but I do not know if GTK/X thinks of
> "paint/expose" operations as very low priority like Windows does.
>
> A typical example from Windows would be a user clicks a covered window,
> bringing it to foreground by clicking the scroll down "down arrow" on a
> scroll bar. In Windows you get the scroll message before the paint since
> paint operations are low priority.  My code "scrolls" by copying the window,
> scrolling, and repainting the "fresh" area. So I use the Win32 UpdateWindow
> API call to "flush" any pending repaint operations before I do a screen
> copy.
>
> All my code goes through my own home grown "API" and my API has an update
> window call. I am trying to find a way to implement this defined
> functionality in GTK.

This is actually quite complicated, and Owen may be one of the few
people in the world qualified to answer the question. I'm not really,
but I would know where to start looking.

I believe you can't naively do the following in X:

 1) flush all updates you have pending
 2) copy area

because there's a race condition; you could get expose events in
between step 1) and 2). Another trick is that you can't copy_area an
obscured area of the window; if you set the graphics exposes flag in
the GC passed to copy_area then you'll get expose events on the
regions that would have been filled in with the obscured portion of
the copied area.

One possible good news is that in GTK+ 2.0, you simply implement
expose/draw handlers, and GTK will automatically do scrolling in the
most efficient possible way using copy_area when appropriate. So you
can ignore this issue entirely. You could also have a look at the
GdkWindow code in CVS and see how it all works (though it isn't
trivial, since it makes things transparent to the user).

Havoc