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 <tiagoma...@gmail.com>: > On 13 May 2011 18:59, Mike Paquette <paquette...@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@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
