On Thu, 9 Aug 2012 12:44:43 -0400 Kristian Høgsberg <hoegsb...@gmail.com> wrote:
> On Wed, Aug 08, 2012 at 02:43:21PM +0300, Pekka Paalanen wrote: > > Krh, was the the idea of first sending all new surface attributes, and > > then committing those at once on wl_surface::attach rejected, or was > > this part of the protocol just not fixed yet? Or is there some other > > clever mechanism to make this atomic? > > It wasn't rejected, just never implemented. The problem is that in > practice it's not necessary, since typically the protocol buffer will > ensure atomicity. Even if that gets flushed unexpectedly, most > clients will re-render in response to frame events or input events, > which we send out at the beginning of the frame, giving clients a > (just under) 16ms window to get things done before their requests > might get broken across two frames. Errm... > But yes, the fact that it is possible isn't really compatible with > "every frame is perfect". Mostly I've just been afraid of > overengineering this, but maybe we can just specify that certain > requests are latched until the next surface.attach request. As a rule > of thumb this would apply to all requests that alter state that > depends on the buffer size or contents. This would apply to opaque > and input regions, and in fact, wl_shell_surface.set_fullscreen > already works this way. > > It's also pretty easy for extensions to tie into this. They just > document which properties are latched. For example position of > overlaid surfaces or buffer contents rotation could be done that way. > > By the way, the way it works now, we invalidate the input region if we > attach a buffer of a different size, but I'm thinking that that's very > un-wayland-ish and we should just always expect the client to attach a > new input region. Yes! :-) I've actually pondered, if we should implement a Weston "synchronous" debug mode, where after handling every single protocol request it would force a repaint (not damage) and make sure the repaint hits the screen. Maybe even add a delay to let possible glitches stay longer on screen. Considering we don't run thousands of requests per second with a few clients, it shouldn't be unbearably slow, just slow. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel