On 11 May 2011 20:25, Bill Spitzak <spit...@gmail.com> wrote: > Michal Suchanek wrote: > >> Moves and resizes implemented in the client can't work well. > > Any resize solution that does not allow an atomic on-screen update of a > window to it's new size, with the resized decorations and contents, is > unacceptable. The whole point of Wayland is that the user NEVER sees a > partially-updated window. > > It is therefore impossible to finish a resize without waiting for the client > to update the window contents. Since you have to wait for that, there is no > reason the client can't also draw the decorations. I'm sorry if this makes > writing clients harder. Deal with it.
Then rewrite all the applications. When you are done with that we can get rid of server side resizes. > >> So the user initiated resizes should happen in the compositor which >> paints the current content in the window of the new size and can >> possibly mix in some haze to make it obvious that the window was not >> resized yet and later the application should update the content size >> to match the window size and move any toolbars appropriately. > > That would look like crap. The window would blink rapidly between the "haze" > and final version. Oh, come on, can't you came up with some real excuse? With all the various effects the compositors implement have you never heard of fade-in? Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel