Experiments with Windows 7 window management
spitzak at gmail.com
Mon May 16 14:02:23 PDT 2011
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.
More information about the wayland-devel