[racket] GUI does not paint while window is resizing on Windows XP

At Fri, 2 Dec 2011 03:35:24 +0000, "Jeff C. Britton" wrote:
> If I hold onto a corner and keep dragging it, eventually it appears that an 
> event is missed and then the window can be resized without painting taking 
> place.  You need to keep dragging the corner for 30 seconds to a couple of 
> minutes.

That behavior is the result of a compromise between the Windows model
of events/threads and the Racket model of eventspaces.

As you are resizing the Window, the Win32 toolbox runs a modal event
loop. During that kind of loop, evaluation at the Racket level is
constrained; a Racket thread switch is not allowed, because the thread
switch would change the C stack and confuse Win32 during any call back
to Win32 function.

Racket's GUI library therefore goes into a kind of best-effort mode
during modal-event callbacks. It runs the usual event callbacks, but
only for events whose destination is the same eventspace as the
original modal-triggering action, and only if they complete quickly
enough. For many purposes, this best-effort handling works well, and
many callbacks succeed to refresh, say, the DrRacket window as you
resize it or scroll around in an editor. If a callback ever misses the
deadline, however, then evaluation of all callbacks are suspended until
the modal loop is done.

Problematic modal loops are ultimately always under the control of an
end-user. For example, a bad program in a different eventspace cannot
keep DrRacket's refresh from happening, but a user who continues to
resize the DrRacket window can delay the refresh indefinitely.

> Is it possible for the user to handle the window size event?

To be clear, all of the usual callbacks happen during a resize (for the
eventspace of the window that is being resized), but only as long as
they complete fast enough and don't try to synchronize with other
threads.