Wayland Window Management Proposal

[Rui Tiago Cação Matos]

On 13 May 2011 18:59, Mike Paquette <paquette.mj at gmail.com> wrote:
> I hope you guys don't mind my chiming in here.

Speaking only for myself as mostly a lurker on this list, I very much
welcome your insightful and experienced remarks. Thanks for sharing!

> The way I handled a window resize was to grow or shrink the window buffer and onscreen region  as requested by the client, mark it as invalid, and hold off on compositing it until the app indicated the buffer was valid, or had good content again.  A timer in the server acted as a backup for this, to allow display update treating the window as containing only the background or autofill color for compositing purposes, so things like running an app under the debugger wouldn't render the display unusable.  The compositor treated an 'invalid' buffer as being a 1x1 pixel buffer holding the background/autofill color, scaled up to the onscreen window size.
>
> The window resize request could specify that content was to be preserved relative to the window origin with new content areas autofilled with the background color, or the buffer would just be filled with the autofill color, or that the buffer would be left as-is because the app would completely repaint the content (as-is could look pretty bad if not repainted, what with the wrong rowbyte values and all...).
>
> It did take a bit of work to convince a few app developers that when they resized a window, they should immediately fix up the content without wandering off to query the odd remote database, but the majority of apps appeared to be ready to redraw content promptly on doing a resize.

Completely agree. The compositor/WM has no business in working around
application bugs. If application programmers are lazy and can't get
their windows acting timely on input then, the ecosystem (users,
distributors) will just "naturally select" those apps out and the well
behaved ones will just be more popular.

Hiding badly designed applications' problems is just rewarding bad
work and, in this case, it's even worse. If the compositor acts on
input before the application draws the final frame it will create
graphical "flashes" (background color, autofill, junk, whatever) for
*every* application which actually penalizes the good ones because the
graphical glitch will be there, even if for a single frame, since this
is inherently how server side asynchronous actions behave.

Rui