Experiments with Windows 7 window management

[Bill Spitzak]

William Swanson wrote:

> Expanding the window leaves unpainted
> background clearly visible for about 3/4 second during updates.

Windows unfortunatly draws into a single buffer that the compositor is 
using, so you still see partial updates like this. They may be unable to 
avoid this as the api for double buffering assumes only the "interior" 
of the window is double buffered.

My understanding is Wayland will not have this problem, as the resize of 
the window will be the *last* thing done by a client, not the first. It 
will first draw the entire new resized window into a new buffer, then as 
the last step it will change the window size and change the buffer as an 
atomic operation. (clients can act like Windows, but Wayland allows this 
double buffering and I expect most/all toolkits will use it).

> Debugged applications: On the
> other hand, the window "snaps" to its new position once the debugger
> releases it. This is surprising. It seems like the OS is queuing drag
> events for the window, even when those events involve moving outside
> the window rectangle.

All "drag" events have to go to the window that got the "push", not to 
the window below the mouse. This is true of X and Windows and OS/X and 
(I assume) Wayland. So this is not a surprise.

Either the Windows get-event api, or perhaps the window handling api, is 
reading ahead and consolidating all the drag events so only the last one 
is acted on, thus producing the snap you see. Such behavior is highly 
recommended for any Wayland client.