[PATCH 2/2] shell: account for the subsurfaces when going fullscreen or maximizing

Pekka Paalanen ppaalanen at gmail.com
Tue Feb 26 12:56:40 PST 2013


On Tue, 26 Feb 2013 12:10:18 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > Do I understand correctly, that you would like to add protocol, so
> > that clients could provide information, that the server can
> > easily compute from the information it already has?
> 
> Yes you understand correctly, except that it is *not* information the 
> server has and I sure would not use the term "easily compute" for the 
> posted code. I prefer this fix rather than the much more complex fix of 
> adding api to say whether a subsurface contributes to this, and clients 
> possibly adding dummy clear subsurfaces just to force this to come up 
> with the correct answer.

It *is* information already present in the compositor. All
sub-surfaces contribute, period. There are no contribute toggles or
dummy sub-surfaces, I do not see any reason for them or for clients
to try to lie about their window area. I see no reason to add any
further protocol. Can you provide a use case where such would be
needed? Something that is based on current upstream and proposed
protocols?

The only debatable thing is, whether all surfaces that are a part
of a single solid window contribute their full size, or just their
input regions' worth. And I'm not sure we even need to specifically
define that in the protocol.

It is very easy to compute. We do that kind of computations in
the compositor all the time. It's just a union of rectangles, and
the bounding box of that, which pixman makes practically trivial to
achieve.

> > Sorry, I don't think so. There needs to be some other reason to add
> > more protocol.
> 
> Which I then provide below:
> 
> >> If there is api added so the client knows what portion of the surface is 
> >> actually visible and not clipped by output edges or panels, it can use 
> >> this to avoid allocating buffer for and drawing invisible portions, 
> >> which I think will be a big win by making maximize a lot simpler.
> > 
> > I have no idea what you are trying to say here. Do you want to
> > change how maximize works? So that clients would always render full
> > decorations, the compositor would clip some decorations away
> > because the window is maximized, and then you want the client to
> > query the compositor about which areas it is clipping away, so that
> > the client would not need to draw them?
> 
> Yes again you seem to understand what I am asking for.

Eh, I was just going for the most crazy, ineffective, and stupid
scheme I could come up by thinking for a while, as I didn't seem to
get your point.

I did write lots of comments for your further reply, but then I
realized I just do not understand what you are suggesting, so my
replies are probably totally off, too.


- pq


More information about the wayland-devel mailing list