[PATCH 2/2 weston] toytoolkit: Don't draw shadows for maximized windows.

[Bill Spitzak]

Scott Moreau wrote:

>     1. The "content" region. This is the part of the window that does
>     not include the "edges". However it *does* include the titlebar.
>     Imagine the "part of the window you see when it is maximized". This
>     is different and smaller than the input region
> 
> 
> No it isn't. The input region and your theoretical content region are 
> exactly the same.

The input region includes the window edges, which is outside the region 
I am talking about.

There may be a failure to understand exactly what pixels I am talking 
about. Lets zoom way in on the right edge of a Windows95-style window 
which is filled with solid green. Here are the (approximate) colors of 
the right 4 pixels:

	green light-gray darker-gray black

The green pixel is inside my proposed region. The light and dark gray 
pixels are inside the input region (because the user can click on them 
to resize the window). Thus my region is smaller than the input region.

(The black pixel probably is inside the input region as well, though I 
think it should be outside to properly get snap-to-outside-edge 
behavior, it can be considered a very dense shadow).

If you maximize the window, you can see that my region is what is lined 
up with the edges of the output and with any panels around the screen. 
Thus this region has meaning. A "maximized" bit is insufficient as it 
does not describe other states such as maximized-vertically.

>     and should be specified by clients using a new api very similar to
>     how the input and opaque regions are specified. Shells need this
>     information to property implement snap-to-edge (where the edge is of
>     another window, a panel, or an output),
> 
> 
> No it doesn't. We can do snap-to-edge for any edge with the input and 
> surface areas known already.

You can only snap to the *OUTSIDE* of the edge. There is no indication 
as to where the inside of the edge is. This information is needed to get 
proper snap to inside edge and to snap windows to each other or behind 
panels.

>     2. When the shell tells a client to configure a window, it should
>     communicate both a size for the surface image, and the bounding box
>     of the content region in this new size.
> 
> 
> It already does this and it's called the input region.

Sorry, I do not see any shell event saying what the input region size 
should be. The client can tell the shell, but not the other way around.

If this was added it would work, though it has the unfortunate fact that 
it would have a negative top-left corner for a maximized window. That is 
why I would prefer that the shell communicate the contents region.

It does not remove the need for the shell to know the contents region, 
since the shell cannot correctly do snap to inside edges without it.

> To make your point more specific, why not submit a patch implementing 
> what you think should happen? I'm not really sure why you're doing this 
> whole write up without any code to show.

I have been trying for a few months to successfully compile Wayland. It 
used to work but has failed ever since the api freeze. I did upgrade the 
machines being used to the newest Ubuntu but this hardly made things better.

At the moment the display I have is skewed unless the surfaces are a 
multiple of 16 pixels wide. It is obvious that some stride requirement 
is not being communicated correctly from the driver to the client, but I 
did not want to annoy the list until I tried to figure out how this 
information should be sent.

It also is dreadfully slow because, despite changes to the driver and 2 
updates to the entire os, and changing the window manager to 4 different 
ones (both compositing and non-compositing), and following suggestions 
that I alter compositing settings) I still have the problem that 
x11_compositor only sees one event and then insists on redrawing the 
screen. Does anybody else have this problem?