Re: more on re- draw at end of re-size

[Havoc Pennington <hp redhat com>]

"tony K." <tony kwok 3web net> writes:
> In order to perform a lengthy graphics generation only at 
> the  end of the user window resize operation, when the 
> mouse button is released (there was a posting on the 
> topic a few days ago), I found a way to do it without the 
> use of timers  (worked, but was to ugly for words...).

The suggested way is to have the user turn on wireframe resize instead
of opaque resize. ;-) Or make your graphics generation be
interruptible, so that receiving GUI events will take priority;
e.g. do the graphics stuff in an idle handler a bit at a time. Of
course that can be difficult or impossible in some cases. (Sometimes
you have to use threads for this.)

In any case, there's no simple solution to the general problem here,
which is how to perform a blocking operation without locking the GUI.

> The top level window - it seems - receives from Xwin  an 
> extra GdkEventConfigure event when the user releases 
> the button at the end of window resize operation.  This 
> results in two  duplicate, consecutive TLW configure 
> events, easy to detect and trigger graphics (on pixmap) 
> regeneration.
>
> Is it safe to assume this behaviour to be consistent 
> across X versions and window managers/desktop 
> systems?

Nope. The configure events during resize are exactly the same as the
ones when the button is released; you can't depend on being able to
distinguish the two cases.

> What is the significance of send_event item in
> GdkEventConfigure structure? The API states something
> to the effect that 1 means it was sent explicitly by
> XSendEvent - as opposed to what...?

The send_event flag means that the event originated from an X client
(in this case, possibly the window manager, though GTK may also
generate events on occasion) rather than from the X server.

Havoc