Wayland Window Management Proposal

[Mak Nazečić-Andrlon]

Alright - who can think of a good enough excuse for a real-world
application to not use a separate GUI/event thread? Even in a
pathologically latency-ridden environment, I'm quite certain that in 1
second the event-handling thread could get a timeslice to respond that
it's alive.

Mak

2011/5/13 Rui Tiago Cação Matos <tiagomatos at gmail.com>:
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>