[PATCH weston] shell: Don't draw shadows for maximized windows.

[Pekka Paalanen]

On Thu, 9 Aug 2012 12:44:43 -0400
Kristian Høgsberg <hoegsberg at 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