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

[Bill Spitzak]

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.

> 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. You are correct 
that clients will probably take adavantage of this by just resizing the 
buffer to the clipped area and changing their drawing origin so the 
edges are clipped correctly. This is how toytoolkit did maximize the 
last time I looked, so I guess it is not objectionable. I think the 
savings in not reallocating buffers is going to be far larger than any 
savings by skipping drawing, but skipping drawing is possible with this.

Weston currently lacks any ability to maximize against less than 4 sides 
of the output. But after looking at per-edge flags to replace the 
maximize flag, I realized that this clip provides all the information 
needed, and also allows clipping of shadows as windows approach the 
edge, and docking on both the inside and outside of edges, and removal 
of edges by tiling window managers. Since this clip seems to cover a lot 
more uses I think it is the correct api, for the very reason you state 
of keeping the protocol small.