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 :
> On 13 May 2011 18:59, Mike Paquette 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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
